Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [starter-dev] Decision - dynamic or static Archetypes?

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.
 

From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Jeyvison Nascimento <jeynoronha@xxxxxxxxx>
Sent: Monday, November 14, 2022 12:08 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Decision - dynamic or static Archetypes?
 
Before anything, just to align definitions:
static = Keep only one set of files and use template logic inside of them to make it work for all cases
dynamic = Separate templates by JEE version/technologies(JPA,REST, etc..)

As Reza mentioned, at the beginning we went with the dynamic approach as you can see here: https://github.com/eclipse-ee4j/starter/tree/archive/starter-core/src/main/resources. But the project didn't have any traction and it was kinda complex for the time, so when Reza joined we talked about it and decided to go to a more simpler approach for the time being that has resulted well.

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 :-)

Ivo.

On 14 Nov 2022, at 16:49, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:

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.

Ondro

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.

1)

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. 

2) 
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.




On 14 Nov 2022, at 06:41, reza_rahman@xxxxxxxxx wrote:

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.
 

From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Ondro Mihályi <mihalyi@xxxxxxxxxxx>
Sent: Sunday, November 13, 2022 11:50 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Decision - dynamic or static Archetypes?
 
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.

Ondro

On Sun, Nov 13, 2022 at 10:45 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:

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 desired.

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.

On 11/13/2022 2:58 PM, Reza Rahman wrote:

As promised, I read through all the messages carefully and attempted to tabulate the decision record so far: https://docs.google.com/spreadsheets/d/1bthiYVjX_UK7Xp2qQmq93awPwVhVCDnprGdzeMtv_ow/edit?usp=sharing. Could everyone here kindly take a look and make sure I got it right? It would also be very helpful to fill in any gaps with your viewpoints (the entire sheet is editable).

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.

On 11/12/2022 9:16 AM, reza_rahman@xxxxxxxxx wrote:
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 right.

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.


From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Jeyvison Nascimento <jeynoronha@xxxxxxxxx>
Sent: Saturday, November 12, 2022 7:39 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Some updates on the progress made lately
 
Wow, being here from the beginning i can say that is really awesome to see so many people involved on this =D

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 this project.

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> escreveu:
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 :-)

Complete example 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


Ivo.

On 12 Nov 2022, at 07:21, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:


Hi, all,

It's great to see so much activity on the Starter project.

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 the archetype
  • 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 archetypes.

Ondro

On Sat, Nov 12, 2022 at 3:11 AM A N M Bazlur Rahman <bazlur@xxxxxxxxx> wrote:
Hello everyone,

I am thrilled to be a part of this initiative and grateful to everyone who nominated/voted for me to be a committer.

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.

Thank you,

-Bazlur

On Fri, Nov 11, 2022 at 11:49 AM Ralph Soika <ralph.soika@xxxxxxxxx> wrote:

Hi all,
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 starting point.

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 runtime:

https://github.com/rsoika/ralphs-microservices

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 here?

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".

For example:

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 ;-)


===
Ralph

Am 11.11.22 um 08:22 schrieb Ivar Grimstad:
Greetings 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 Web UI.

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 straightforward.

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 do, though. 
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 another if-statement...).

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 have options.
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.

Ivar
--
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
--

Imixs Software Solutions GmbH
Web: www.imixs.com Phone: +49 (0)89-452136 16
Timezone: Europe/Berlin - CET/CEST
Office: Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph Soika

Imixs is an open source company, read more: www.imixs.org

_______________________________________________
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
_______________________________________________
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

_______________________________________________
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
_______________________________________________
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
_______________________________________________
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