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

I must say I don't see the rationales here or must really be missing something or there is a communication gap.

The parameters are a minimal set and exactly what we would specify using a UI or any other mechanism. The way Maven Archetypes handles them is quite sensible and something most people that use Maven Archetypes can easily understand.

I really am quite lost as to what the issue is with embedded databases and containers and why demonstrating the alternative with a PR would be hard.

Lastly, what would the additional README explain I really don't understand either beyond what the index.html and starter docs already do. Can you provide some example content to illustrate?

Is some of this easier to sort out in a meeting? Perhaps too much context is being lost in a text based medium? I am not sure.

On 4/30/2022 3:40 AM, Ivo Woltring wrote:
See my comments below

On 30 Apr 2022, at 00:17, reza_rahman@xxxxxxxxx wrote:

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.


I agree that the current archetype is fairly modularised. the trouble with that it is not immediately evident what it does. Are there so called ‘-D’ options?
If you have multiple archetypes with only the standard archetype questions a user can easily generate a project with the "mvn archetype:generate” command.

e.g. [code]

$ mvn archetype:generate -Dfilter=nl.ivonet:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< org.apache.maven:standalone-pom >-------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:3.2.1:generate (default-cli) > generate-sources @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:3.2.1:generate (default-cli) < generate-sources @ standalone-pom <<<
[INFO]
[INFO]
[INFO] --- maven-archetype-plugin:3.2.1:generate (default-cli) @ standalone-pom ---
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> nl.ivonet:jakartaee8-essentials-archetype (JakartaEE 8 project minimalistic quickstart template.)
2: remote -> nl.ivonet:jakartaee8-payara-microprofile-archetype (Jakarta EE 8 / Payara 5 / Microprofile 3 - project minimalistic quickstart template.)
3: remote -> nl.ivonet:jakartaee9-payara-microprofile-archetype (Jakarta EE 9 / Payara 5.2022.1 / Microprofile 4.1 - project minimalistic quickstart template.)
4: remote -> nl.ivonet:javaee7-essentials-archetype (-)
5: remote -> nl.ivonet:javaee8-essentials-archetype (Java EE 8 project minimalistic quickstart template.)
6: remote -> nl.ivonet:javaee8-payara-microprofile-archetype (Java EE 8 / Payara 5 / Microprofile 2 - project minimalistic quickstart template.)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): :

[/code]

Also now you can easily choose what base you want to generate from which is way easier that having one base with a lot of options. Currently you first have to say No to the default provided options before you can change them and choose e.g. another runtime when running from the command-line.

[code]
$ mvn archetype:generate -Dfilter=org.eclipse.starter:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------< org.apache.maven:standalone-pom >-------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:3.2.1:generate (default-cli) > generate-sources @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:3.2.1:generate (default-cli) < generate-sources @ standalone-pom <<<
[INFO]
[INFO]
[INFO] --- maven-archetype-plugin:3.2.1:generate (default-cli) @ standalone-pom ---
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> org.eclipse.starter:jakarta-starter (This is the official Eclipse Foundation starter for Jakarta EE.
It generates code to help get started with Jakarta EE projects
using Maven. It is possible to do so using Maven
archetypes. Support for a UI may be added at a later point.)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): : 1
Choose org.eclipse.starter:jakarta-starter version:
1: 1.0.0
2: 1.1.0-SNAPSHOT
Choose a number: 2: 2
[INFO] Using property: groupId = org.eclipse
[INFO] Using property: artifactId = jakartaee-cafe
[INFO] Using property: version = 0.1-SNAPSHOT
[INFO] Using property: package = org.eclipse
[INFO] Using property: runtime = payara
Confirm properties configuration:
groupId: org.eclipse
artifactId: jakartaee-cafe
version: 0.1-SNAPSHOT
package: org.eclipse
runtime: payara
 Y: : n <————————————— Saying NO is not nice IMHO
Define value for property 'groupId' org.eclipse: : nl.ivonet
Define value for property 'artifactId' jakartaee-cafe: :
Define value for property 'version' 0.1-SNAPSHOT: :
Define value for property 'package' org.eclipse: : nl.ivonet
Define value for property 'runtime' (should match _expression_ '(?i)^(payara|glassfish|tomee)$') payara: : tomee
Confirm properties configuration:
groupId: nl.ivonet
artifactId: jakartaee-cafe
version: 0.1-SNAPSHOT
package: nl.ivonet
runtime: tomee
 Y: :
[/code]

Personally I like long explaining names (java :-)) to make choosing and using easy. That is user value and not maintainer value.



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.

The trouble right now is that if I make a PR (which I want to) to “fix” this container issue it is also in the code that runs if you run it without container on the host machine. It would then also point to that location on the host machine and that might not be wanted behavior. This is one of the main reasons why I stimulate in my archetypes to always run in a container even in the development phase. There are very nice ways of doing that. I will think on this :-)


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?

Yes I mean a generated README.md. If you want to keep it simple what is better than explaining in the readme how to basically use the generated project and have the basic “how to run” chapter already filled in. 

I totally agree with the license file. Didn’t think that completely through :-)

 
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





_______________________________________________
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

Back to the top