Toned down the Maven4 sec dispatcher messages. Also, IF maven3 passwords detected AND there was `.mvn/extensions.xml` the warnings were doubled.
Examples:
Failure to start Maven (due non-decryptable passwords):
```
$ mvn clean
[ERROR] Error executing Maven.
[ERROR] Error building settings
* FATAL: Could not decrypt password (fix the corrupted password or remove it, if unused) {xL6L/HbmrY++sNkphnq3fguYepTpM04WlIXb8nB1pk=}
* WARNING: Detected 2 pre-Maven 4 legacy encrypted password(s) - configure password encryption with the help of mvnenc for increased security.
$
```
Warning at start (due Maven3 passwords):
```
$ mvn clean
[INFO]
[INFO] Some problems were encountered while building the effective settings (use -X to see details)
[INFO]
[INFO] Scanning for projects...
[INFO] --------------------------------------------------------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Apache Maven
...
```
---
https://issues.apache.org/jira/browse/MNG-8424https://issues.apache.org/jira/browse/MNG-8419
Currently mvnenc is unable to log to file (-l) as logging setup is incomplete, move all of this logic to LookupInvoker. Also, create prompt in mvnenc only when needed. Finally, implement needed changes to support mvnenc ITs and add mvnenc IT.
Other changes:
* get rid of `distributionFileName` dirty hack, is remnant from old ITs
* fix CI re removal of that above and use of site that is brain-dead
---
https://issues.apache.org/jira/browse/MNG-8421
* [MNG-8388] Fix escape characters being replaced to change the original configuration
Signed-off-by: crazyhzm <crazyhzm@apache.org>
* Add unit test
---------
Signed-off-by: crazyhzm <crazyhzm@apache.org>
Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
The goal of this PR is manifold, but major one is to be able to use in ITs new options introduced in Maven4. Currently the "embedded" mode supports only Maven3 options, as Maven4 got new CLI entry point (CLIng), while verifier uses old MavenCli entry point, that is also deprecated. Finally, a full cleanup of (black) magic happened as well, keep ITs simple and clean.
Changes:
* dropped from ITs classpath maven-shared-util
* dropped from ITs classpath maven-verifier, copied last master Verifier to maven-it-helper and modified
* enhancements to new maven-executor to make it fully replace maven-verifier
* ITs are now using new infra and are using new CLIng "entry point" as well (so far ITs used deprecated maven-embedder/MavenCLI class).
---
https://issues.apache.org/jira/browse/MNG-8403
* [MNG-8389] MavenExReq lacks u/p/i settings file paths
The "effective" paths for 3 settings file was not set on
MavenExecutionRequest.
---
https://issues.apache.org/jira/browse/MNG-8389
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.
The decryption should happen transparently, also, resolver should not decrypt for itself only, whole maven should have access to all.
This PR also disables Maven 3.0 IT MNG-4459 as Maven4 stops with this "security through obscurity" (keep encrypted pw in memory kinda for "security reasons" but in reality any mojo or extension can decrypt anything they want).
---
https://issues.apache.org/jira/browse/MNG-8379
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
Detach maven-cli from maven-embedder (deprecated). Basically, classes are copied from embedder to cli, while embedder points to old classes and cli to new classes. **One important exception is logging**: the classes are _moved_ to cli, and embedder modified to use those classes (and dependency reversed: embedder now depends on cli). Reason is Verifier, that still calls into "hack method" of deprecated MavenCli, and then without logging classes move would explode due casting.
---
https://issues.apache.org/jira/browse/MNG-8332
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
Guillaume Nodet
Tamas Cservenak
Jermaine Hua