Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [starter-dev] Starter archetypes / GUI / Issue #67
Hi Everyone.

On one hand I understand Ivo's POV about the benefits of having this granularity but I wonder if this is needed at all for now.
The project is (still) really small and we shouldn't have to deal with something like this for what we have today.

Also, I completely disagree with the multiple repo's approach. This can get too spread and may confuse whoever is willing to help us in the project.
And if we really wanna have more archetypes, A multi-module project should be enough rigth?

In the future, yes, maybe we will need more archetypes since the original idea was to provided multiple examples wit the different apis, something that probably cant be reused easily.
I'm just questioning if thats the right moment, since we already have a roadmap to cover


Em seg., 2 de mai. de 2022 às 08:07, Ivo Woltring <ivo@xxxxxxxxx> escreveu:
If you make an archetype that can do a lot of things and configure a lot then it becomes more difficult by definition.
How do you test such an archetype with all its options? Generate all combinations with every change and see if it still works?

DRY is in my opinion not always the best way to go, but I see your point.

What of a compromise?

A bare bones project with only the maven project and Dockerfile of choice and one with all the demo thingies and options in it.
One for new blood to learn and one for those who just want a new project so they can start jamming?




On 1 May 2022, at 08:03, reza_rahman@xxxxxxxxx wrote:

So I had a quick side chat with some of the folks that develop our various Maven Archetypes for Azure just to validate what I had been planning. They confirmed that this is not just doable but very normal for what is typically done in post-processing scripts for non-trivial Archetypes. Indeed it is rather simple compared to much more advanced capabilities like in this example script they shared: https://github.com/microsoft/azure-maven-archetypes/blob/develop/azure-functions-archetype/src/main/resources/META-INF/archetype-post-generate.groovy. This is the use cases that post processing scripts are for after all as opposed to the more basic Archetype templating features.

Still, I am happy to actually prototype out what I had in mind so folks here can take a look and hopefully see for themselves how much not a big deal this really is.

Now, I am not saying that if the generated project varies too much in reaction to parameters that there isn’t a sensible case for creating a separate Archetype. For example, I can see a generated JSF CRUD project being sufficiently different from the current REST CRUD generated code. But fairly minor variations for Jakarta EE versions and target platform? I think that’s no big deal at all. Even the relatively simple Payara Micro Archetype handles Jakarta EE versions just fine as parameters: https://docs.payara.fish/enterprise/docs/documentation/ecosystem/maven-archetype.html.
 
From: reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx>
Sent: Saturday, April 30, 2022 8:14 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Starter archetypes / GUI / Issue #67
 
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.
 
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, April 30, 2022 2:03 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Starter archetypes / GUI / Issue #67
 
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




On Fri, Apr 29, 2022 at 9:41 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:

Certainly a welcome idea, though hopefully not an "as-is" donation but a merge?

For example, are separate Archetypes really needed? I think for folks using it from the command line and IDE, just one Archetype would be far easier. As such, it is very easy to modularize Archetypes instead of exposing the user to the complexity of multiple Archetypes I think (you can hopefully see that in the code currently in the main branch and various runtime support).

On 4/29/22 3:06 PM, Ivo Woltring wrote:
Hi y’all,


A Couple of weeks ago I was triggered by the new https://start.jakarta.ee/ archetype and have been playing with it.

The last couple of years I have maintained a couple of javaEE/jakartaEE maven archetypes and exposed them to the web: https://ivonet.github.io/archetype/
Just now I saw the issue created by Ivar https://github.com/eclipse-ee4j/starter/issues/67 and that made me think.

If the community is open to it, I would love to join the effort and possibly ”donate" all my archetype related material.
It is already open source but right now under the Apache2 license. That is also open to change as I am the sole committer on these projects.

Please let me know what you think.

Kind regards,

Ivo Woltring.

@ivonet



_______________________________________________
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
_______________________________________________
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev


--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 
_______________________________________________
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev

_______________________________________________
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev


--
Jeyvison Nascimento

Back to the top