Re: [starter-dev] Decision - dynamic or static Archetypes?

["reza_rahman@xxxxxxxxx" <reza_rahman@xxxxxxxxx>]

Just to be clear, I am in full agreement as I believe we have been all along.

Right now it really does not feel sound to segment along the lines of pretty much any of the major variants. For example, I think splitting along the lines of Jakarta EE version winds up causing as much as 80-90% duplicated code, much worse than what we have even now.

That’s not to say a clearer evolutionary path wouldn’t become apparent as we move forward, make a bit more progress and mature the project a bit more. Splitting things later is fairly easy and we can even make a reasonable effort towards backwards compatibility for folks using the Archetypes directly instead of via the UI.

 

---

From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Jeyvison Nascimento <jeynoronha@xxxxxxxxx>
Sent: Wednesday, December 28, 2022 11:42 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Decision - dynamic or static Archetypes?

 

I believe the consensus is that we should go ahead with an approach of making the Archetypes as dynamic as possible and evaluate later if evolving to an Archetype by Jakarta EE version would be helpful.

+1 on that too but we have to keep an eye out for pom.xml. It's the only file that's getting a little bit too complex with all the jakarta/runtime versions. Maybe it's not worth splitting it now but we must be careful about its maintainability.

--

Jeyvison Nascimento