[MNG-8615] [MNG-8616] Maven core extensions handling improvements

[cstamas]

It all started with MNG-8615 to not swallow DI problems while loading core extensions. Then tried to add origin as well, but it turns out there is lack of context. Then turned out models are not location tracking. Then came MNG-8616 as Maven was too rigid and did not apply precedence for extensions making project hopping problematic, if not impossible...

Changes:

• do not swallow DI issues happened during core extension loading; belly up instead.
• report which extension caused DI issue
• make core extension models and IO location tracking
• alter CLI api to carry all extensions "by origin" (project, user, installation)
• parser should be plain dumb, all it does is load extensions in precedence order and validates them (validity: they must be GA unique)
• DI capsule performs now "selection" of extensions (based on precedence) and loads them as before
• finally: we have now DEBUG logs which all extensions were considered and which were effectively loaded, something I missed a lot
• new UTs revealed MavenInvokerUT problem: ClassWorlds were not cleaned up properly

Behavioural change since 4.0.0-rc-3:

• conflict within same source (same file) makes Maven fail - as before
• conflict spanning across sources is warning only; precedence is applied to select extension to be loaded

---

https://issues.apache.org/jira/browse/MNG-8615
https://issues.apache.org/jira/browse/MNG-8616

[michael-o]

https://media1.tenor.com/m/HEMQmYHww6MAAAAd/borat-borat-very-nice.gif

[cstamas]

Example of conflict and DEBUG output:

[DEBUG] Configured core extensions:
[DEBUG] * USER:
[DEBUG]   - eu.maveniverse.maven.mimir:extension:0.4.0 -> /home/cstamas/.m2/extensions.xml:3
[DEBUG] * PROJECT:
[DEBUG]   - eu.maveniverse.maven.mimir:extension:0.4.0 -> /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3
[WARNING] Found 1 extension conflict(s):
[WARNING] * Conflicting extension eu.maveniverse.maven.mimir:extension: /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3 vs /home/cstamas/.m2/extensions.xml:3
[WARNING] 
[WARNING] Order of core extensions precedence is project > user > installation. Selected extensions are:
[WARNING] * eu.maveniverse.maven.mimir:extension:0.4.0 configured in /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3
[DEBUG] Selected core extensions:
[DEBUG] * eu.maveniverse.maven.mimir:extension:0.4.0: /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3

[gnodet]

Example of conflict and DEBUG output:

[DEBUG] Configured core extensions:
[DEBUG] * USER:
[DEBUG]   - eu.maveniverse.maven.mimir:extension:0.4.0 -> /home/cstamas/.m2/extensions.xml:3
[DEBUG] * PROJECT:
[DEBUG]   - eu.maveniverse.maven.mimir:extension:0.4.0 -> /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3
[WARNING] Found 1 extension conflict(s):
[WARNING] * Conflicting extension eu.maveniverse.maven.mimir:extension: /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3 vs /home/cstamas/.m2/extensions.xml:3
[WARNING] 
[WARNING] Order of core extensions precedence is project > user > installation. Selected extensions are:
[WARNING] * eu.maveniverse.maven.mimir:extension:0.4.0 configured in /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3
[DEBUG] Selected core extensions:
[DEBUG] * eu.maveniverse.maven.mimir:extension:0.4.0: /home/cstamas/Worx/apache-maven/maven/.mvn/extensions.xml:3

Why do we consider a conflict if the extension is the same (same GAV + same config) ?
That's not really a conflict. A conflict would be a different version or different config imho.

[cstamas]

Why do we consider a conflict if the extension is the same (same GAV + same config) ? That's not really a conflict. A conflict would be a different version or different config imho.

We consider it as "conflict" for simplicity sake: I'd not go down the route to have "model builder" for extensions, and "build" the model out of 3 sources. Even if same GAV of extension, project one may have different config due some requirement while user wide another config, etc.

I'd keep handling them dead simple: they are considered as "blob" (atom?) keyed by GA and no merging or building or whatsoever magic happens, basically rules are simple:

• one XML file must be GA unique (having two different entries Vs for same GA is most probably error; nor Maven can handle that)
• across 3 possible sources precedence wins

[gnodet]

Why do we consider a conflict if the extension is the same (same GAV + same config) ? That's not really a conflict. A conflict would be a different version or different config imho.

We consider it as "conflict" for simplicity sake: I'd not go down the route to have "model builder" for extensions, and "build" the model out of 3 sources. Even if same GAV of extension, project one may have different config due some requirement while user wide another config, etc.

I'd keep handling them dead simple: they are considered as "blob" (atom?) keyed by GA and no merging or building or whatsoever magic happens, basically rules are simple:

• one XML file must be GA unique (having two different entries Vs for same GA is most probably error; nor Maven can handle that)
• across 3 possible sources precedence wins

Yeah, I fully agree we don't need merging or whatever. I was simply thinking about a slightly less dead simple approach: for a given GA, either there's a single entry or V + config is the same.