I think it is worth noting that a benefit of splitting the archetypes into one per Jakarta EE version is that we would then be able to keep the Maven coordinates (groupId and artifactId) consistent over the lifecycle of the archetypes. Another benefit is to be able to name the archetypes more specifically. e.g. org.eclipse.starter::jakartaee8, org.eclipse.starter::jakartaee9.1, org.eclipse.starter::jakartaee10, and so on.
For the zip-generating server, or any other tool we build around the archetypes, naming is of little importance, but I suspect the majority of use will come from direct usage of the archetypes through IDEs. And for that purpose, I would advise that we think about the naming and make the split first.
Just for full context, Jeyvison, Bazlur and I had always agreed to keep modularity in mind and evolve as we go forward together, hopefully with all committers. There will be some impact to anyone using the Archetypes directly during refactoring, but honestly for the primary target Starter UI users, this is a pretty low level implementation detail in our consideration.
The sub-folder/override technique you mention is actually one we explored too and still use to a certain extent to have some internal modularity. For the minimal vs. REST CRUD use case, we thought that wasn’t a good approach as a lot of the code was truly substantially different, even for the generated POMs. That’s how we wound up with two still pretty dynamic Archetypes right now and not just a single one.
Going with a single archetype in the beginning until it's too hard to maintain and then split it for new EE versions sounds good to me. I just wanted that we agree that going with different archetypes for new EE versions is an option, we don't have to do it immediately.
I'm not an expert on archetypes, but maybe we can even find a good option to have a single archetype and avoid complexity. For example, maybe we could have a folder for every EE version inside the resources folder, so that we can add/override files for a specific version of EE.
I think the first priority for me is that we discuss these matters together, come to a reasonable agreement and try our best to respect that agreement going forward. I agree with Jeyvison and presumably Bazlur as well that it is not really necessary right now to split the Archetypes by Jakarta EE version. If we can agree on the use cases, that’s a much more sensible way to split Archetypes. That’s the way we had it for the 1.0 release.
If we start this way, I think it’s always possible to split further later on if it actually turns out the code varies substantially from one Jakarta EE version to another. There may also be other reasons to have separate Archetypes as things evolve. I think it’s generally easier to modularize later than try to merge/consolidate later.
However, I do not think I am categorically opposed to splitting the Archetypes by Jakarta EE version and use case if that’s the final outcome once we discuss properly and tally input. It would not be that much work to refactor right now and we can always observe/adapt as we progress the work whether that was the right call or not. Similarly it’ll be a bit more maintenance of duplicated code but not nearly as bad as if we had no dynamism at all.
But as the project grows and we introduce new technologies I think it will get harder to get all combinations working( i'm kinda dealing with this already in one of the PRs). I'm not against separating them again and maybe rewriting some(or a lot) of our code if it will mean that it will be easier for us to maintain.That would be the second time I would do this in this project anyway XD.
I'm not sure if we need to split it by versions though. We already have placeholders for the jakarta prefix(as we had before) , jakarta version, and specific imports or small snippets of code can be omitted or added depending on the version. That change is not worth splitting the templates, but if we wanna have more examples, with different technologies, with code that is really hard to be reused, then it makes sense to split things.
Thanks for the appreciation, Ondro ^^
Em seg., 14 de nov. de 2022 às 16:19, Ivo Woltring <ivo@ivonetnl> escreveu:
+1 on every bullet you mentioned and also the appreciation at the end :-)
Yes, I recommend having a separate archetype for each EE version because of all that other people mentioned. And, I add a few more reasons:
The more combinations a single archetype will support, it's more likely that an enhancement for one EE version will break something for an older EE version. We would have to carefully test that what we add doesn't break things that were working before
It's then easier to maintain archetypes for older EE versions. If there's a runtime that doesn't support the latest EE version (e.g. EE 10), we simply won't add it to the archetype for the latest EE version. But we can easily update the version of a runtime that supports EE 9, if the vendor releases a newer version of it. We won't need to create a complicated algorithm to choose which runtime works for which EE version and how to support multiple versions of the same runtime in the same archetype, if there are some changes besides the runtime version number (e.g. a change in deployment descriptors, deployment plugins, etc.)
in case of Jakarta EE 8 vs 9, we could simplify the archetype and just use the jakarta prefix. I know that we could have just 2 separate archetypes for EE 8 and then for EE9+, but this is only an example of how much simpler it would have artefacts specific to each EE version.
I also need to say that I really appreciate Bazlur's and Jeyvison's effort and we can still keep it for all the other dynamic aspects of archetypes, but the code would be really much simpler if we had separate archetypes for each EE version.
On Mon, Nov 14, 2022 at 2:18 PM Ivo Woltring <ivo@xxxxxxxxx> wrote:
There are at least two good reasons for why putting all versions and combinations into one archetype is a bad idea is as follows.
Every if you have to write adds complexity (KISS principle) and complexity invites mistakes.
Avoiding any kind of added complexity is preferable even it is “relatively” little.
A version of an archetype will eventually stop being maintained. Probably when a newer major version of Jakarta EE is released. If you have them in a separate archetype that archetype code is just there and will never have to be updated again. The artifact is also still there in maven central and does not need maintenance at all. There is no added complexity at all.
If you have it in your "one archetype to rule them all” it does need to be maintained because there will be a new “if" and eventually you may need to remove code as it may not be compatible anymore.
I would honestly like to understand this point of view a bit better. Bazlur, I and Jeyvison actually have code already that handles both Jakarta EE 8 and Jakarta EE 9.
Virtually all the Java code remains the same and we simply parameterize the namespace in Groovy. Similarly all we do in the POM is dynamically generate the Maven dependency version via Velocity. Would it help if Bazlur shared that code to see how it actually looks like? It is honestly very modest both in terms of volume and complexity (thus maintenance effort) compared to most line of business applications I have seen, let alone commercial grade software.
Indeed we tried it both ways very early on and observed together that due to the very high degree of code duplication if not using dynamism, even a small change in the duplicated code becomes a needlessly cumbersome maintenance exercise. As much as it’s tempting to think code won’t change, it always inevitably does. There’s always unforeseen bugs, enhancements, runtimes that produce updates to older releases, new Java version support added to older runtime releases and so on, not to mention Jakarta EE 8 might yet prove to be much more long lived than we expect.
Anyway, at least would love to hear what Bazlur and Jeyvison think about this since they too have been working with the dynamic approach for a while now and we did arrive at that approach collaboratively together after some level of careful analysis/discussion.
My view is that, sooner or later, we'll need to use dynamic archetypes, if we want to allow users to choose which code examples, which runtime, which Java version etc.they want. It will simply be too many combinations to create a separate static archetype for each.
But, as some suggested, it makes little sense to mix Jakarta EE versions in the same archetype, as it may get too complicated and hard to maintained.
So I suggest that we introduce dynamic archetypes for each Jakarta EE version. For a new version of EE, we'd create a copy of the archetype, adjust it for the new version, and continue maintaining only the archetype for the latest EE version, for various Java versions, runtimes, etc.. We could update older archetypes when needed, for example to add support for a new runtime, but I would keep changes to older archetypes to absolute minimum.
The recently committed work relies on a set of static Maven
Archetypes that do not make significant use of input parameter
validation, Velocity templating or Groovy scripting capabilities
built into the Maven Archetype framework. There are essentially
separate Archetypes for each input parameter than can vary such as
Jakarta EE version, Java SE version and Jakarta EE profile
The prior direction some of the committers had been pursuing is
to build a small set of highly dynamic Maven Archetypes that make
full use of input parameter validation, Velocity templating and
Groovy scripting within the Maven Archetypes framework to generate
the code examples. The code generated by a single Archetype can
basically vary depending on various user input including Jakarta
EE version, Java SE version, Jakarta EE profile, Jakarta EE
namespace, and preferred runtime. An example can be seen here: https://github.com/eclipse-ee4j/starter/tree/master/minimal-starter.
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.