Make the command-line tool correspond to what the modello-maven-plugin can do

[fridrich]

What does this change?

This adds some command-line options to account for modello-maven-plugin options. All the options are incrementally optional. This allows to generate the source code using the command-line in the same way modello-maven-plugin would do.

This allows us to bootstrap some packages within distribution build environments, where maven needs modello-maven-plugin to generate its sources, but modello-maven-plugin is maven plugin and needs maven to run. The usual circular dependencies that make it really difficult to bootstrap stuff.

I don't expect this feature to have a ton of users out there, but I am carrying these patches for years and they are not breaking anything in upstream modello, so I would not mind them to be integrated.

[fridrich]

I got a change of mind. With the new plural exceptions parameter, I realized that this stuff of positional arguments is extra-super fragile. So, I take the positional argument version that was there until now and add another, more scalable way, with --* arguments.

[slachiewicz]

as this is new/upgraded feature - lets assume it will b eversion 2.9.0 for since tag

[slachiewicz]

can you also take a look at #15 if is still valid?

[fridrich]

can you also take a look at #15 if is still valid?

I normally did not have this kind of problems, but given the injection, the right classpath is of essence. I am generating the script called modello in our openSUSE rpm build using this command:

%jpackage_script org.codehaus.modello.ModelloCli "" "-Dguice_custom_class_loading=CHILD" modello:aopalliance:atinject:commons-lang3:google-guice:guava:jackson-core:jakarta-inject:javadoc-parser:jsoup/jsoup:objectweb-asm/asm:plexus/plexus-build-api:plexus/plexus-build-api0:plexus/classworlds:plexus-containers/plexus-component-annotations:plexus/utils:plexus/xml:org.eclipse.sisu.inject:org.eclipse.sisu.plexus:slf4j/api:slf4j/simple:snakeyaml:velocity-engine/velocity-engine-core %{name} true

where modello is actually a directory with all the jars minus maven plugin. Some dependencies, like plexus-xml or jakarta-inject are there because of which version of plexus-utils and guice we use. The classpath is known to work well and I am generating on command-line all the code needed for build of maven 3.10.x and 4.0.x. Although, the maven 4.0.x needs two additional patches extending the positional arguments. Now with the plural exceptions, I came to a point when I realized that 11th optional positional argument will be a huge mess. So, I came with this syntax.

[fridrich]

as this is new/upgraded feature - lets assume it will b eversion 2.9.0 for since tag

Changed that as a fixup of the commit moving those constants. Also fixed the javadoc:javadoc, by adding the artifact modello-plugin-velocity as additional dependency for the maven-javadoc-plugin. Besides that it can be scope runtime as the others. Eventually they could be all optional according to which generator is needed, but that is bigger change and would need more testing of cross-module dependencies.

[fridrich]

Any chance this could be integrated? With the upcoming maven 3.10.0 release, the aliases will be needed and -- if it is possible -- I would prefer not to carry over a huge patch.

[slachiewicz]

Thanks, this works for me end to end: named options and the legacy positional form both generate the same sources, and spotless plus ModelloCliTest pass on JDK 17. Two things before merging:

1. Please keep VELOCITY_BASEDIR, VELOCITY_TEMPLATES and VELOCITY_PARAMETERS in VelocityGenerator as @Deprecated aliases of the new ModelloParameterConstants fields. fedora-java/javapackages-bootstrap (mbi/modello/.../ModelloTool.java) references them and would no longer compile against 2.9.0.
2. --packagedVersions only sets modello.all.versions. The mojo also regenerates once per packaged version with packageWithVersion=true (AbstractModelloGeneratorMojo#doExecute), so --packagedVersions 1.0.0 does not produce the versioned package the plugin would. Either loop the same way in main or document the difference in the usage text.

Minor: a repeated key in --params or --plural-exceptions ends in an IllegalStateException stack trace instead of the usage message.

[fridrich]

1. Please keep `VELOCITY_BASEDIR`, `VELOCITY_TEMPLATES` and `VELOCITY_PARAMETERS` in `VelocityGenerator` as `@Deprecated` aliases of the new `ModelloParameterConstants` fields. `fedora-java/javapackages-bootstrap` (`mbi/modello/.../ModelloTool.java`) references them and would no longer compile against 2.9.0.

Ok, I added them back as deprecated basically forwarding them to the ModelloParameterConstants. I added a javadoc comment about the new constants.

2. `--packagedVersions` only sets `modello.all.versions`. The mojo also regenerates once per packaged version with `packageWithVersion=true` (`AbstractModelloGeneratorMojo#doExecute`), so `--packagedVersions 1.0.0` does not produce the versioned package the plugin would. Either loop the same way in `main` or document the difference in the usage text.

Now the CLI does the same. Sorry for the omission :(

Minor: a repeated key in --params or --plural-exceptions ends in an IllegalStateException stack trace instead of the usage message.

I extracted the parser of parameters into a parseMap method that checks for duplicates and fires usage instead of the exception. I had to change the implementation, because only catching the exception and firing usage would eventually cover more cases then just the duplicate key.

While checking the usage text against the generators, I found one extra issue: Xpp3WriterGenerator reads modello.xpp3.extended.suffix without a fallback when location tracking is on, which only happens for xpp3-extended-writer. The xpp3-extended-writer mojo always passes it (defaultValue = "Ex"), but the CLI and other direct callers such as ModelloTool don't. Running --type xpp3-extended-writer without --extendedClassnameSuffix therefore generated a class named ...Xpp3Writernull.

My commit makes the generator default to Ex when the parameter is absent, which matches the mojo's default. Maven builds are unaffected: the xpp3-writer goal never uses the suffix, and the xpp3-extended-writer goal always sets it. The guard around the read was redundant, since the only use (the writer class name) is already conditional on isLocationTracking().