Provide way to customize some of resolver SPI providers

[splatch]

The upcoming release of Maven Resolver will drop support for ServiceLocator: https://issues.apache.org/jira/browse/MRESOLVER-157 which is extensively used in pax-url-aether module.
There is an PR which addresses that: apache/maven-resolver#88, so changes can be cross checked already.

This means that some kind of IoC handling will be necessary in this project, unless it is switched to ie. guice which probably will remain. Pax never really had any support for IoC and customization of created resolver (which I found few years ago while working on version range handling), so I would like to bring this topic once again.

There are actually two use cases I would like to bring:

• Customization of resolution process (ie. version ranges)
• More advanced repository authentication (based on certificates, tokens and other things not managed via static settings.xml file)

I know that none of above is currently possible because pax-url does shading of Maven and Aether packages. But, even if above extensions would be compiled against pax'ed packages there will be no way to get them dynamically included by the resolver.
Hence this issue is made with an "epic" label to see if such customization will be ever possible.

[grgrzybek]

Thanks for heads up @splatch

Hmm, this sounds a bit dangerous. When I was playing with maven (aether) resolve I found the DI model nice and elegant, but not 100% suitable for embedded use, where you simply create few objects/services and tie them together.

Switching to DI mode only would require pax-url-ather to really start a full plexus container first and obtain a resolver from it. To make it proper, we'd have to open pax-url-ather to extensions provided by sisu/guice/maven modules discoverable via OSGi and I can't imagine (yet) how to do it in simple way...

Mind that we're NOT forced to switch to maven-resolver without service locator at any time (unless the previous versions disappear from Maven Central ;)). I'll think more about it.

BTW, I'm thinking about pax-url-war improvements to adjust to my Pax Web 8 changes - although it works without any changes, I could make it more flexible in terms of which web packages are imported by the webified bundle...

[cstamas]

Don't forget that DI (Sisu/Guice) is still not a MUST for maven-resolver (there are no class dependencies on it)... you can still introduce some (your own) helper class like MavenResolverBootstrap that does all the "boilerplate" work that DI does for us (creates instances using "good old way"), as this was basically what ServiceLocator was doing. Still, if you want some "dynamism", for example you throw new resolver transport onto classpath, and expect it to be auto-picked up, you'd better go with SISU as it would do all this for you. But, AFAIR, ServiceLocator was NOT doing this, so all you really need is just one boostrap class that does the resolver instance creation for you.

[grgrzybek]

For the record, Camel is already using custom DI registry based on JSR330, which can configure entire Maven Resolver without service locator. See apache/camel#8501.

[cstamas]

FYI https://github.com/maveniverse/mima

[grgrzybek]

Thanks @cstamas - I'll have a look.