Yet another CLIng cleanup.
Changes:
* pull out Executor, it does not belong to CLIng (new maven-executor module created with no deps)
* resident and maven invoker fixes (proper handling of resources now), no more SO/OOMs
* enabled UTs in maven-cli (that revealed the issues)
* small bug fixes discovered in cli, improved executor to reveal maven version
---
https://issues.apache.org/jira/browse/MNG-8386
And make use of it in CLIng. Also, move from "late" Resolver session factory to "early" CLIng invocation of `PropertyContributor` SPI and make contribution visible across whole Maven, not only Resolver.
---
https://issues.apache.org/jira/browse/MNG-8385
This is just a cleanup of exception usage (by making them checked, fixing compiler issues, and undoing the change). There are at least two bugs (runtime escapes) fixed in this PR.
First part was to "reverse" MavenCli into CLIng, that also became a huge and complex beast. Now, sanitization comes, tearing down unneeded stuff. CLIng should be simple and straightforward.
Now the **invoker** fully parses args, creates Maven instance (ie. local, using Maven components on classpath) and invokes Maven. The new **executor** in turn does NOT fully parses args and is logical equivalent of maven-invoker.
Changes:
* radically simplify CLIng existing classes (and especially API - the fact we have "local", "resident" etc invoker is actually implementation detail).
* introduce "executor", a "lower level" tool that does not parse args (and is logical equivalent of maven-invoker) and support Maven 4.x and Maven 3.x.
---
https://issues.apache.org/jira/browse/MNG-8375
As counterpart to maven.repo.local.tail, but this one "prepends" while other "appends". This means one can do like this
```
$ mvn install -Prun-its -Dmaven.repo.local.head=~/.m2/repository-it
```
And have stuff installed into dedicated IT local repo (as IT bits must be installed), instead to pollute own local repo.
---
https://issues.apache.org/jira/browse/MNG-8370
To have them listed in generated docs, as they were forgotten.
Also, adding a "compat" support for Maven 3.9.x property for chained reposes.
---
https://issues.apache.org/jira/browse/MNG-8362
First, `rootDirectory` is nullable, CLIng code was not assuming this, fixed.
Second, emit the "no root found" warning ONLY when appropriate (when we have a POM in picture).
---
https://issues.apache.org/jira/browse/MNG-8302
Implements the `mvnenc` tool that is on par with Maven3 master password encryption functionality wise, but is _really secure_ unlike Maven3 conterpart. On the other hand, _is backward compatible if legacy config is setup_.
Implemented goals: `init`, `encrypt`, `decrypt`, `diag`. Also provides one extra "master source" based on Maven infra Prompter: console master password prompt.
---
https://issues.apache.org/jira/browse/MNG-8285
Changes:
* there is only one parser for "just maven", no need for 3
* aligned scopes (public) of local context for simplicity, we can fix visibility later
* allow custom guice modules (unused, may undo this)
* split logging setup in two steps: config and activate
---
https://issues.apache.org/jira/browse/MNG-8283
This PR adopts CLIng for use in mvnd, and adds several improvements to CLIng overall.
Major topics:
* ability to pass in per-request Lookup for customization
* makes parser request creation a bit friendlier
* removes a log of redundancy (same stuff copied over)
* ability to alter rootDirectory detection in parsers
* resident invoker bugfix
* adds UTs for 3 invoker implementations
---
https://issues.apache.org/jira/browse/MNG-8283
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.
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`.
---
https://issues.apache.org/jira/browse/MNG-8283
With the introduction of the build pom and raw -> build pom transformation, the construction of the effective poms in two steps become very problematic. Over the time, multiple caches have been added to the ProjectBuilder and ModelBuilder related classes which are often redundant.
This PR thus changes things and move the recursive construction of the models fully into the ModelBuilder in a single call. When building build poms, a first step is done by parsing the file models from the root, then building all needed effective models from those. All the inference can be cleanly done because the builder has all the file models ready. The result will be used by the ProjectBuilder to build the projects.
Javadoc states wrong things (about format of modelId, they are
paths in reality), but also these all are "implementation details".
Crafting modelIds to "walk" lineage is wrong, there is a dedicated
method that provide "opaque" key Strings in defined order to
do that. And client should not care (nor assume) anything
about format of the key String.
---
https://issues.apache.org/jira/browse/MNG-8233
Tamas Cservenak
Guillaume Nodet