[MNG-7974] Update Resolver 2.0.0-alpha-5

[cstamas]

Update to Resolver alpha-5 and apply some cleanups.

Notable changes:

• update resolver to 2.0.0-alpha-5
• detach model-builder from maven-artifact (this is important)
• introduce model builder own VersionParser iface (implemented in resolver-provider)
• API VersionParser implementation reuses VersionParser from resolver-provider to implement the service
• various other cleanups, removal of old plexus, etc

---

https://issues.apache.org/jira/browse/MNG-7974

[gnodet]

What about all the usages of org.apache.maven.artifact.versioning.DefaultArtifactVersion ?
This is currently the one used in the Maven 4 api and also in areas such as parent selection in model building.

[cstamas]

@gnodet see da737af

[gnodet]

I'm not sure I'm buying the use of the additional indirection for the VersionSchemeSelector. I wonder if it would be just as simple to be injected with a VersionScheme. If users want to use a different scheme, they just need to register one with a higher @Priority. And if we want pluggability, we could also define a @SessionSCoped component that would delegate to the VersionSchemeSelector underneath.
But at least, components would simply be injected with a single VersionScheme.

[cstamas]

The goal of this PR is to allow transparently per-session choice of VersionScheme. The "transparently" means that even the constructed object graph can be retained, as all the selection happens at session runtime, hence this would work also in mvnd without any extra effort as well. Finally, yes, this opens ability for users to really shoot themselves in foot (which maven config does not do that so far?), but I think the benefit of this -- ie. to have some custom version scheme with project specific (fixed) version scheme outweighs that.

Also, don't forget that this allows now for a Mojo to customize session (and configure version scheme for use case) and then perform different queries against resolver...

VersionScheme is a resolver interface, and while Resolver does not instantiate it anywhere directly, it is always client code that needs to set it (ie. see util filters etc), but as this PR shows, there are some resolver component implementations (am looking at maven-resolver-provider) that use it. Hence, this PR makes this feature available for Maven but also for any Resolver 3rd party integration as well.

Reason why would you use different VersionScheme is usually due comparisons between versions, ordering. And remember, Maven does not do such thing, as plugins in POM, dependencies are usually "plain versions" where simple string equality (or translation via layout and on retrieval equality) is applied, are mostly unaffected by scheme. Where scheme comes into play is version sorting, range handling and such...

Finally, don't forget that currently regarding versions there are two "parallel universes" (both with own bugs), the maven-artifact Version and resolver Generic version scheme. This could also open a gate to drop one of them, and have two implementations of Scheme like "generic" and "legacy", that implements old one with all of it's bugs, hence users could choose "modus operandi", "current" or "legacy".

[cstamas]

Reworked PR: stepped off selector, it was reverted (see https://issues.apache.org/jira/browse/MRESOLVER-457 and read why it was bad idea). All simpler now.

[cstamas]

I agree with 49cec29 commit: if component changed to session scope, no need for provider.
But I don't understand 2nd commit 5ce5279 that left components singletons, but you removed the provider.

Can you explain that? As your 2nd commit makes mandatory to rebuild component graph in case of schema change, while with provider it was possible without doing that.

[gnodet]

I agree with 49cec29 commit: if component changed to session scope, no need for provider. But I don't understand 2nd commit 5ce5279 that left components singletons, but you removed the provider.

Can you explain that? As your 2nd commit makes mandatory to rebuild component graph in case of schema change, while with provider it was possible without doing that.

So what kind of schema change do you have in mind exactly ?

I'm not buying the idea to use Provider at the injection point to control the lifecycle of dependent beans. If we suppose a plugin can register any kind of component and that it should override the default component set, then all injection points have to use Provider. Such components are supposed to be provided by extensions, which do not change. Fwiw, I think we do overuse the @Singleton and most components are defined as singletons but this is unnecessary because they are stateless. @Singleton should be used for classes that actually need to be singletons.

[cstamas]

Ok, let's postpone this discussion, am completely fine if this PR merely upgrades Resolver to alpha-5.

My ultimate goal is to kill off "parallel universe" (two version implementations, resolver and maven), but for sure this PR is not fixing that. And agree with overuse of singletons as well.

Let's move on with this if you are fine with it.

[cstamas]

@gnodet this PR became "just" update to resolver-5 w/ cleanup. So please review it as such.