Yes, I already created a working prototype for the CLI using an archetype programmatically the same way as the servlet does. When I get around to it, I'll submit a PR so you can have a look at it.
It is very easy to switch the actual generation to an HTTP call to a service when that is up and running. For the UI, it makes sense with the ZIP format, no arguments there. And as you point out, there is no issue unpacking it in the CLI either.
But we don't have to wrap the maven project generator if we decided that it's better that the CLI tool retrieves a ZIP from a remote REST services. It looks like more people prefer this approach. A simple service is already implemented, currently with a servlet that accepts arguments as query parameters: https://github.com/eclipse-ee4j/starter/blob/master/starter-ui/src/main/java/org/eclipse/starter/ui/StarterServlet.java. The CLI tool would just need to unpack the downloaded ZIP file. This is what the UI uses to generate the ZIP to download - the UI basically links to this servlet, which can be deployed on a completely separate domain and URL.
The recently committed work includes a CLI facade over a handful
of static Maven Archetypes.
This is wrong!
There is no such work committed yet. There is a suggestion to do so. And that is a suggestion that I would stand behind as it would be using the same generation mechanism as when the archetypes are used standalone, or as the mechanism to generate contents of a zip file on a server.
The prior direction some of the committers had been pursuing is
to first build out support for the smallest set of mostly
self-documenting dynamic Maven Archetypes and a Starter UI (that
supports both Maven and Gradle). A CLI would be considered later
mostly to better support Gradle in the command line (e.g. invoking
'gradle init' behind the scenes on a generated Maven project).
I don't agree.
I have had a look at picocli and it looks very promising. I should be able to have a prototype ready for all to review shortly. If someone want to do the same using Gradle, have at it. Let's do a comparison then.
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.