| Re: [starter-dev] A few questions / discussion items on archetype 1.0.0 |
See my comments below
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: : Personally I like long explaining names (java :-)) to make choosing and using easy. That is user value and not maintainer value.
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 :-)
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 :-)
|