I think the spreadsheet was excellent to get an overview of various inputs at a certain point in time. But it is a snapshot of opinions and does not contain the nuances, or background. And people change their minds, so it is volatile. I think I would just leave it as it is. It has sort of served its purpose by sparking off the various discussion threads.
Having healthy, constructive dialogue focusing around each topic in the threads is what I would suggest.
Ivar, how important is it that people need to explicitly “sign off” before we begin an intermediate analysis of outcomes? My view is that people providing input here are responsible enough such that this is unnecessarily. If you truly feel this is necessary, I will add a “sign off” row and ensure everyone fills it out. It will take additional time and effort on my/others part to do so, but I am happy to do it for us to achieve committed agreement we can confidently move forward together on.
Understood. Let me put some thought into what either the most critical or easiest decision point is and also what a reasonable sequence of decisions are. We can then discuss each decision with a view towards committing to reaching agreement, taking into account the input patterns as they stand on Sunday. I haven’t looked closely yet, but it does look like there are clear patterns on most items already. We should be able to reconcile the diverging code streams without significant loss of contributions.
The desire is indeed to ultimately result in detailed GitHub issues with links to discussion/input including hopefully milestones, priorities and initial committer/contributor assignments.
I think the number of points discussed has been overwhelming, at least for me. It's difficult to track all emails and reply to all threads. I would wind down the discussion after Sunday, record what we have, decide on priorities. And then I would continue discussing each point again, from the highest priority ones, a single point at a time, and iterate. When we have a clear view about the highest priority point, implement it, and only then continue discussing the next point. Otherwise I'm afraid many of us will get lost in too many parallel discussions.
As an alternative, we can create a github issue for each point and discuss each topic in its github issue, but that doesn't solve the problem with tracking all the parallel discussions. So, even then, I suggest focusing on one topic at a time.
I have to say I am a bit worried that the conversation has slowed down so soon. I do see a lot more of the sheet is full, which is awesome. However, I still see that there are a lot of empty spots. I also think there is a lot of room for good discussion on topics such as use cases (at least a good solid initial take).
It’s of course possible some folks are still absorbing the discussion and rethinking their initial viewpoints (I certainly am) Your thoughtful input is very appreciated. I worry without sufficient input, discussion and agreement we will have unproductive decision drift that’s painful to deal with for people volunteering on their free time.
Is it reasonable to aim to begin to wind down discussion by the end of Sunday but not too much earlier? I think we can then begin tabulation, building agreement and moving forward in a committed direction together.
I definitely agree we should wait a bit more to do a final tabulation (my guess would be at least a week or more). Folks should definitely review, update and change to reflect their current viewpoints as we progress the conversation.
I am planning to do a final review prompt before we start a tally and determine outcomes. I think the outcomes are best determined in an in-person meeting and then communicated here.
I have updated my column so it reflects my viewpoints more accurately. I encourage everybody to do so, and I would refrain from using this table in any way until everybody mentioned there have "signed off" on their viewpoints. The ones that were recorded for me were seriously skewed.
It is a good idea to set up a regular call. When we have found a timeslot for it, I'll help set it up with the EE4J Zoom account.
I am out of time today but should be able to share my own
viewpoints by some time tomorrow late evening. Hopefully the
emails this afternoon will help generate thoughts, discussions and
ultimately committed decisions together. I would like to get back
to hacking on this project during nights and weekends once overall
direction is once again a bit better understood. It took me a
while to secure permanent Azure hosting for this project on our
managed Jakarta EE PaaS (App Service). Thankfully that's all done
now and can be used if a server-side portion for the Starter UI is
something we ultimately still pursue.
Another thing I think we need to schedule soon once we get a
chance to have some more async online conversation is a regular
sync meeting (maybe once a month?). I think not having that is one
of the factors that has caused some mismatched
expectations/assumptions, misalignment, and unnecessary surprises
we should be able to avoid going forward hopefully?
I will now try to start separate threads on the distinct
decision points so we can hopefully better structure the
discussion, capture input for more traceable archival and
achieve reasonable decision outcomes easier. I'll also outline
the rationale for my own viewpoints separately.
I am very grateful responsible folks from
the community as well as current committers have taken
the time to help us agree on directions. I believe more
views from more folks will be forthcoming soon.
I think it will help to see where consensus
is if I broke out each key question/decision into a
separate thread. For each decision point, I will read
each message carefully and include a tentative vote per
decision/person that I will record and keep updated in a
Google Sheet. Please do help me make sure I get it
I will also include my own views at this
point. I think that may also help set additional context
for folks that have not been very intimately involved in
all the project activities so far.
Wow, being here from the beginning i can say that
is really awesome to see so many people involved on
I think the approach based on maven archetypes was a
good way to get things going but I feel like this is
something too much related to the Jakarta EE community.
If we wanna reach other developers we should try to make
things easier(or more build-tool agnostic).
While it's good to have a minimum archetype so we have a
project bootstrapped and ready to be used, if wanna new
developers to learn and understand how things are used,
one of our goals has to be provide project with usage
examples(for transactions, JPA, etc...) or else it will
become a generator for people that already knows Jakarta
EE and i think that's not the original proposition for
The CLI could be a good addition but I don't see it
as a MUST for now. I agree with Ondro that we should
have a GUI to download the ZIP file and I submitted a
proposal for that some time ago. I'll attach it here.
In summary: I agree we should have more examples with
different apis, not just the minimum, and we should
decouple the project generation from the maven
archetype, hiding it behind a GUI.
In the future we can have Gradle as an option too,
but I think these both above items will already require
a lot of us.
Em sáb., 12 de nov de
2022 às 07:02, Ivo Woltring <ivo@xxxxxxxxx>
Like Bazlur I am very happy to be part
of the community now. Forgot to mention that in the
heat of the discussion :-)
I also work a lot with junior developers. One of
the first things they learn is how to work with
maven as it is the most important build framework
out there. Generating a project from the commandline
with maven should not be a big problem for most. I
do not see the added benefit if generating a zip
first and making that the download. The only thing I
can think of is that the user does not yet have
maven installed. Hmm maybe it is a good idea :lol:
Ondro I am interested in looking at that code of
yours too :-)
projects are very useful. They teach a wow and the
correct way. But
Maven archetypes ar not meant to generate
complete example projects but working skeletons so
you can add your own functionally easily. Copy and
pasting a project to strip it down defeats the whole
purpose I think.
I think that heaving complete examples is a great
idea and they should be made, but in tutorial
fashion like the spring guides. Not as part of an
archetype. I don’t know if generating a zip in this
case is necessary as it can just be a git project or
many git projects.
I like the idea of a Cli. Kinda like ng does.
Not only to generate a base but maybe even add
e.g. a controller or somesuch.
I really like the basic starter as we have it now
and I think a barebones starters should always be
available because that is how I mostly start and
that is a very good reason hehe
It's great to see so much activity on the
I like the approach the Starter project
did initially, to get things started and
simple - just generate a maven command line
to execute. It was at the time when the
Started project didn't have many
contributors. And using maven archetypes is
a good starting point.
But my vision for Starter resonates with
other ideas mentioned in this thread:
It would be good to provide an option
to download a ZIP file generated from
Provide example projects, or even make
it possible to generate an example
project by selecting the components that
users are interested in (e.g. they
select REST and CDI, and the generated
project would create a REST service with
a bean injected to it beans.xml file,
and a corresponding README that
describes how to build it and how the
components are wired)
On top of that, I'd like to see a REST
endpoint in Starter, so that ZIP file or
Maven command line can be generated with a
script or REST client that connects to the
endpoint. This would allow writing a
Starter CLI or IDE plugins, which would
use the Starter webapp as the backend.
A few years ago, I started writing a
Java app, that generates a ZIP file from
any Maven archetype and I think it would
nicely fit what is already in the Starter
webapp. I'll check what's the state of
this app and will try to contribute it to
the Starter, so that we can generate ZIP
files for download based on the
I am thrilled to be a part of this
initiative and grateful to everyone who
nominated/voted for me to be a
I love what you have all said so far. I
don’t necessarily disagree with any of
Ivar’s points, but let me share my
thoughts about it.
I work with junior developers so that
I can see things from their
perspective. We're all experienced
developers here, so we don't have any
trouble understanding and working
through a low level of complexity.
Everyone here knows the maven
archetype like the back of their hand.
But if we want to get new or less
experienced developers to try out the
Jakarta EE spec, I think it's a good
way to stop them. There are already a
lot of good alternatives that are
pretty easy to use. One example is the
spring boot starter. I can go to the
website, download the project, and try
it out even though I don't know
anything about it.
If you already know about Maven and
the Maven archetype, I don't think you
need this starter project. You can use
GitHub to find a sample project and
start working on it.
From this point of view, I think the
second option Ivar mentioned in the
email is the best one.
So, essentially what I'm saying is:–
Let's make a website where we hide all
the archetype stuff and let the user
download a fully working sample along
with a convenient runtime. The idea is
that the user will download and run
the sample, then hit the browser.
Since this is one of the major
open-source projects I’m contributing
to, I can assure my commitment.
I followed this project and the
discussion in the last view weeks.
I also agree that this idea of a
starter page is really great. And
it's important to give new
developers (who haven't been using
Java EE for the last 10 years) a
For us here, everything that is on
the starter page is completely
clear and the "The Jakarta® EE
Tutorial" explains the rest. But
what I observe is that many new
developers have absolutely no
patience anymore. So I think it
would be good to offer not only a
selection of platforms, but also a
small selection of minimalist
project templates. For example, a
simple RestAPI example with a
Swagger UI or a minimal JPA
example. Some time ago I had
assembled something like this for
a customer in a draft version
including a Dockerfile to provide
a simple start with a default
The goal was to show that Jakarta
EE brings a lot of additional
functionality if you combine it
for example with Eclipse
Microprofile. I don't know what
you think about a Dockerfiles with
a Wildfly or Payara Runtime? Or
whether you consider Eclipse
Microprofiles to be overloaded
But I think that at least we
should somehow give the
profile/template selection a
dynamically reloaded README.md
file that explains a bit what the
template consists of. It may be
enough to point the developer to
the corresponding sections in the
"The Jakarta® EE Tutorial".
This example contains a Rest
Service called '/hello' which is
defined in the class
RestResource. You can add
additional GET, POST and DELETE
resources. Find out more about
the Jakarta EE Rest API here. If you want to load or
store your data from a Database
you can use the Jakarat
EE Persistence API.
I know you think this is idiotic,
but for many new developers these
very simple hints are important to
survive the first half hour ;-)
Am 11.11.22 um 08:22 schrieb
Committers and Contributors,
I am super excited to see
the starter project moving
forward after a little
standstill. There has been
some great progress made
lately! New contributors and
committers are on board. We
now have a simple UI
available at https://start.jakarta.ee that
generates a simple project for
Jakarta EE 8, Jakarta EE 9.1,
and Jakarta EE 10. The
feedback I have received from
the community when demoing it
has been 100% positive.
The UI uses bare-minimum
archetypes to generate the
code. The next steps would be
to add support for runtimes
and possibly explore creating
a CLI as an alternative to the
In addition to the UI,
there are also several
archetypes that generate more
extensive examples being
worked on. Since everything is
based on archetypes, adding
these and potentially other
archetypes created by the
community should be fairly
The archetypes for EE 8,
9.1, and 10 could be
mashed together as one with
the conditional logic inside
the archetype. I am not sure
if this is the right thing to
Keep in mind that as we go
forward with EE 11, 12, 13,
... the older versions won't
need much attention.
Sometimes, a little
duplication is favorable over
adding another branch in the
logic (even if it is just
The option of creating a
server-based solution to
generate the starter
projects is still an option
if someone wants to pursue
this. It is always good to
Personally, I think the
approach to base the starter
on archetypes is a better
and more flexible way to go.
The only server needed is
Maven Central, and that is
already there and not our
problem to maintain. And it
provides the option for
developers to consume the
archetypes directly, via our
UI, potentially a CLI, or
directly in IDEs.
Jakarta EE Developer Advocate | Eclipse Foundation
Foundation - Community. Code. Collaboration.