User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Josh, you shared "I do not think it would be a bad idea to build
upon the minimal to incorporate various configurations which would
enable more 'starting points". In the sheet for use-cases you
indicated "Minimal, REST CRUD, web app (Faces)".
Should I interpret this to simply mean you see us enabling those
use cases to the extent a chosen profile allows? Or do you think
we should allow users to specify distinct APIs separately (e.g.
REST, CDI, Persistence, Enterprise Beans, Validation, Faces, etc)
incrementally with minimal, REST CRUD and web app CRUD (Faces)
being the target state depending on what the user chooses?
Obviously the former is a lot easier and basically what I, Bazlur
and Jeyvison already have. The latter is also doable, but
definitely a bit more work (but not overly so given what we have
in place already). The latter is also more in line with what the
MicroProfile Starter has. One bit of complexity of course is that
Jakarta EE has quite a few APIs, not all of which are used very
On 11/13/2022 4:13 PM, Reza Rahman
The recently committed Archetypes include a minimal "hello
world" rest endpoint code example with no further plans to add
other use cases.
The prior direction some of the committers had been pursuing is
to include two use cases the user can choose from - a minimal
"hello world" rest endpoint as well as a REST CRUD code example.
The REST CRUD code example makes use of an embedded database as
well as a working JUnit test. The corresponding minimal
Archetype is here: https://github.com/eclipse-ee4j/starter/tree/master/minimal-starter.
The REST CRUD Archetype is here: https://github.com/eclipse-ee4j/starter/tree/master/rest-starter.
A web app CRUD example using Faces had been in planning as a low
priority. It can be noted that this is somewhat in line with the
approach for the MicroProfile Starter.
Another possibility discussed early on but not pursued
currently by any current committers is dynamically including
examples in the generated code such as for security, batch,
mail, WebSocket, etc. Yet another possibility is including Cargo
Tracker in the Starter. It is worth noting that Cargo Tracker
currently supports Payara with no short term committed plan or
resources to support other runtimes.
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 right.
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
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 Starter project.
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 the archetype
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 archetypes.
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
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
Since this is one of the major
open-source projects I’m
contributing to, I can assure my
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 starting point.
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
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 here?
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%
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 Web UI.
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 do, though.
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
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 have options.
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
Eclipse Foundation - Community. Code. Collaboration.