[MNG-8283] Maven CLIng

[cstamas]

New CLI for Maven. Goals are reusability, extensibility and easier embeddability (a la mvnd). If you build this branch, you will end up with Maven distro that uses "new" maven-cli:org.apache.maven.cling.MavenCling class as entry point instead of "old" maven-embedder:org.apache.maven.cli.MavenCli.

First step is to make "pretty much equivalent" capable CLI as compared to "old", with some exceptions:

• "encryption" ops are gone, those should be in separate tool anyway
• "deprecated and unsupported" CLI options like -llr present ONLY to make Maven fail are gone (now Arg parser will fail).

Current state of affairs is messy, MavenCli mixes everything it can, contains interleaved logic for bootstrapping, arg parsing, default logic and executing Maven. First goal is to clean this up.

Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens up way to have "alternative" CLI arguments parsers as well.

Note: naming, as always is off. We just could not come up with better names, so "invoker" is used, but they are too generic, and they clash with existing Maven Invoker. But have to say, that this work could replace Maven Invoker on longer run with some much simpler and cleaner solution.

Currently the "local" (CLI) flow is this:

arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ)

But the point is if you "come up" somehow with a Request instance, one can also do just:

Request -> invoker -> maven runs (somewhere)

Local parser:

• parses CLI args
• infers the defaults
• creates Request object that contains all information needed to run Maven
• can be reused outside of CLI as well
• does NOT fiddle with Plexus, logging, etc.

Local invoker:

• accepts Request object
• deals with configuring env (logging, etc), creating DI container, and running Maven ONLY

There are some experiments ongoing as well, like ForkedInvoker is, but also MavenTool.

[gnodet]

Approved but:

• not sure if the org.apache.maven.cling.invoker.mvn.daemon should be in this PR, it may be left out for now
• the ITs are slow and this need to be fixed (seems about always forking)

[cstamas]

The "slow ITs": originally ITs run for about ~17m and in this PR they started to run for ~1h, huge difference. Cause found and fixed: turned out that my change to m2.conf (by adding expression to be able to introduce new CLI tools) made Verifier choke on parsing that config file. In fact, it does use ClassWorld Launcher to parse it, but nothing set the maven.mainClass Java System Property, and Launcher threw exception, but Verifier (that is by the way "mute", have no means to communicate at all, as it already have redirected sysout to same file where Maven starts logging, and when Maven interprets the -l CLI options, it simply overwrites the file with output so far) sneakily and silently fall-back to forked launcher, hence the time diff.

Last run is again ~17m proving that fix works, fix is in IT suite:
apache/maven-integration-testing@7cd5fed

[cstamas]

Re "daemon": is not (yet) daemon, will rename it to "resident" as it will be basis for shell-like and daemon-like use cases. IMO can remain here, and mvnd will (most probably) have some subclass of it.

[DidierLoiseau]

I don’t know if this is expected, but this change breaks running Maven through IntelliJ. Indeed it invokes Maven through java without setting maven.mainClass. Is it expected that all tools which do that will have to add this argument, specifying the main class?

Also note that the exception is a bit confusing since it does not say where this property is being used.

/home/didier/.sdkman/candidates/java/22-open/bin/java -Dmaven.multiModuleProjectDirectory=… -Djansi.passthrough=true -Dmaven.home=/home/didier/.sdkman/candidates/maven/master -Dclassworlds.conf=/home/didier/.sdkman/candidates/maven/master/bin/m2.conf -Dmaven.ext.class.path=/home/didier/.local/share/JetBrains/Toolbox/apps/intellij-idea-community-edition-3/plugins/maven/lib/maven-event-listener.jar -javaagent:/home/didier/.local/share/JetBrains/Toolbox/apps/intellij-idea-community-edition-3/lib/idea_rt.jar=38433:/home/didier/.local/share/JetBrains/Toolbox/apps/intellij-idea-community-edition-3/bin -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 -classpath /home/didier/.sdkman/candidates/maven/master/boot/plexus-classworlds.license:/home/didier/.sdkman/candidates/maven/master/boot/plexus-classworlds-2.8.0.jar org.codehaus.classworlds.Launcher -Didea.version=2024.3 validate
org.codehaus.plexus.classworlds.launcher.ConfigurationException: No such property: maven.mainClass
	at org.codehaus.plexus.classworlds.launcher.ConfigurationParser.filter(ConfigurationParser.java:355)
	at org.codehaus.plexus.classworlds.launcher.ConfigurationParser.parse(ConfigurationParser.java:114)
	at org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:123)
	at org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:116)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:356)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:314)
	at org.codehaus.classworlds.Launcher.main(Launcher.java:41)

Process finished with exit code 100

[gnodet]

I suppose we could make it default to org.apache.maven.cling.MavenCling ...