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 this =D
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 this
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
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
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
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 the
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 committer.
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
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 runtime:
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
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 Ivar
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 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,
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 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
Jakarta EE Developer Advocate | Eclipse Foundation
Foundation - Community. Code. Collaboration.