Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [starter-dev] A few questions / discussion items on archetype 1.0.0
Personally, I think a single Maven Archetype can be fairly easily modularized. This is what we did for multiple runtime support. I actually think having multiple Archetypes is less usable for users not using the UI (and using either the command line or IDE). Indeed to be honest I think having multiple Archetypes is more complex to maintain and makes dynamic templating harder/leads to a lot of needless code redundancy.

With regards to databases, I think any embedded database is fine. The current embedded ones are defined in the web.xml as per Jakarta EE, they are actually indeed managed by the application server and indeed JTA compatible. I think adding a non-embedded database makes the getting started experience needlessly harder. Also, defining the database in an application server specific way leads to less portable code. That said, I think a PR might make it a bit clearer as to what you might be suggesting and how it helps.

Are you referring to a README and license in the generated project? What value would that really add? Maybe a PR better explains the value proposition? The current GitHub repo already has both a README and license that has what you are suggesting?
 
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Ivo Woltring <ivo@xxxxxxxxx>
Sent: Friday, April 29, 2022 5:21 PM
To: starter-dev@xxxxxxxxxxx <starter-dev@xxxxxxxxxxx>
Subject: [starter-dev] A few questions / discussion items on archetype 1.0.0
 
Hi y’all,


I have been playing with the new jakartaEE archetype 1.0.0 and have a few ideas / questions / findings I would like to discuss with you.
The main reason I do this here and not on the issue list (https://github.com/eclipse-ee4j/starter/issues) is that none of these ideas are actually bugs or issues.


Ideas / Questions

  • Is it a good idea to create one archetype per git repo?

The reasoning behind this is that you can easily create a new archetype when needed.
For every example an archetype? 
Every repo separately maintainable and version-able.
A Gui to choose from the different archetypes and examples.
Right now the archetype supports multiple application servers and that makes it more difficult to maintain IMHO.

  • The current archetype has a database in the demo code, but that database is not application server managed. does that not defeat the purpose of a Jakarta project with a database.

Normally when run in an application server I am used to a JTA managed datasource where the application server is responsible for the actual connection.
Maybe that makes the example misleading or confusing for users.

In a Dockerfile it is fully possible to do this. It is not necessarily easy but do-able (https://seashells.io/v/XJpU2VpC)

  • The archetype should have a README.md file with basic information about the how and what of the archetype.
  • and example run scripts.
  • A License file?


So that are some of the things I was thinking about when trying out the archetype :-)
Please let me know what you think.

Have a nice weekend.

Ivo.

@ivonet





Back to the top