Thanks for sending this update. I am certainly very happy to see progress on the projects and also happy to see we can have a discussion together to agree on key decisions. I have already given the existing committers a heads up this is a discussion we need to have soon and I have also pulled in several key folks from the community (including IBM, Red Hat, Oracle, etc) to help us all move forward together. Bazlur, myself and Jeyvison remain fully committed to this project. We do need to reconcile direction between the recent commits and the work the three of us have done, have been doing and wish to continue to do.
I think there are many points of differences of opinion, but I think we need to start by determining collective agreement on the following:
- To what extent do we try to follow the various starters out there that we know are effective such as the Spring Boot, MicroProfile, etc starter vs taking a significantly different direction.
- Does the UI expose Maven Archetypes as an underlying technology or does it remain focused on higher level use cases such as minimal vs crud, Jakarta EE version, profile, Java SE version, etc?
- Do the code examples include the runtime and are immediately runnable without any additional setup or does the user need to figure our how to get the runtime separately and the code examples do not in any way include the runtime?
- Does the UI ask the user to execute more steps to generate the code or does it simply allow the user to download the generated code example?
- Do we make full use of the dynamic capabilities of Maven Archetypes such as Velocity Templates and Groovy Scripts or is it a large (probably several dozen) collection of static archetypes for essentially every single code example line that can vary?
I will post my own views and rationale to these questions in a subsequent email. I would appreciate all other folks here did the same as well and help us achieve overall agreement. I think I understand Ivo and Ivar’s position on these questions but I think it’s still good to add explicit clarity and rationale for everyone so we can move forward together based on a common mutual understanding.
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.
