I have to be honest, I really don’t see why multiple Archetypes would be any easier at all for anyone.
From one Jakarta EE version to another, the only things that would change are Jakarta EE dependency versions, Java SE versions, runtime versions and package names. Those could easily be expressed as variables in the source and filled out using templates in the Groovy post-script (Groovy even has built-in template engines for this). The user simply needs to specify the Jakarta EE version as an Archetype parameter. The Groovy post script can then easily replace a set of variables depending on the user input parameter. This of course in addition to the incremental file replacement technique we already have in the Groovy script. These simple techniques avoid needless complexity for the end user and code duplication while utilizing reasonable modularization.
Before going down the multiple Maven Archetypes road, I suggest taking a look at how that would work. It’s really quite simple, flexible and robust. I can dynamically generate just the Java/Jakarta EE package name for now to demonstrate the technique if you like. I’ll need about a weekend’s time to do that if this is a priority right now.
We need to be able to support multiple versions of Jakarta EE at the same time.
Support for EE 9 and EE 10 is crucial to get out ASAP. For this we have two options:
1. One archetype that supports the generation of multiple Jakarta EE versions
2. One archetype per Jakarta EE version
I think that 2) will get us there faster, and also reduce the complexity of the archetype. Thus apply WET rather than DRY. It would also be clear for the user which version is being generated by this being reflected in the maven coordinates. For example:
org.eclipse.starter::jakartaee8
org.eclipse.starter::jakartaee9
org.eclipse.starter::jakartaee10
...
Ivar