ShrinkWrap Resolver 2.0.0 modifications

[kpiwko]

I'd like you to comment following modification I'm planning to do for upcoming SWR 2.0.0 release:

Resolver Maven Plugin

POC hosted at https://github.com/kpiwko/resolver-maven-plugin

This plugin must be configured in projects pom.xml. It will inject 5 system properties into the surefire environment, making SWR able to retrieve essencial information about the Maven build which started the project.

This plugin should become an core part of the resolver.

Note: M2E integration would be nice, meanwhile user will have to set 5 system properties by his own in the IDE

Keeping Maven related methods out of user's reach

Having Resolver Maven Plugin, user should not have directly exposed APIs to access Maven configuration stuff.

This means that following will not be available by default:

• loadEffectivePom(...)
• configureFrom(...)
• useCentralRepo(...)
• goOffline(...)
• repository(...), repositories(...)

All this information will be transparently set by Resolver Maven Plugin.

Enviroments without Resolver Maven Plugin

It is clear that users trying to run SWR for Ant or different tool will have no Resolver Maven Plugin injection available. These users should have access to the above-mentioned methods, so they can configure Maven environment by themselves.

Implementation

I think the correct way how to solve that is to create two entry points:

• MavenDependencyResolverWithIntegration
• MavenDependencyWithoutIntegration

The idea here is that after MavenDependencyResolverWithoutIntegration is configured, is will become a plain MavenDependencyResolverWithIntegration. We will likely have to modify what methods an EntryPoint provides.

Use cases

1/ Get hibernate-search artifact with transitive dependencies from current pom.xml

DependencyResolvers.use(MavenDependencyResolverWithIntegration.class).artifact("org.hibernate:hibernate-search")

This will fail if integration not detected suggesting user either to activate the integration or to use MavenDependencyResolverWithoutIntegration.

2/ Get hibernate-search artifact with transitive dependencies without a pom file

DependencyResolvers.use(MavenDependencyResolverWithoutIntegration.class).artifact("org.hibernate:hibernate-search:4.0.0.CR2")

It won't trigger any integration stuff. It will use default configuration, e.g. Maven Central enabled and .m2/settings.xml.

3/ Get hibernate-search artifact with transitive dependencies without integration and a pom file

DependencyResolvers.use(MavenDependencyResolverWithoutIntegration.class).loadEffectivePom("pom.xml").artifact("org.hibernate.hibernate-search")

4/ Get hibernate-search artifact with transitive dependencies using Maven configuration specific stuff:

DependencyResolvers.use(MavenDependencyResolverWithoutIntegration.class).goOffline().configureFrom("settings.xml").loadEffectivePom("pom.xml").artifact("org.hibernate:hibernate-searcch")

Access to internals

We should define a way how to let user get information from both Maven model and information retrieved from Resolver Maven Plugin. I like the idea of doing it the ShrinkWrap way, e.g. using some as() method and casting object to a information retriever. Note that this won't be available on MavenDependencyResolverWithoutIntegration for an obvious reason.

DependencyResolvers.use(MavenDependencyResolverWithIntegration.class).as(MavenProjectInformation.class).getPackaging();

DependencyResolvers.use(MavenDependencyResolverWithoutIntegration.class).loadEffectivePom("pom.xml", "as7-rocks-profile").as(MavenProjectInformation.class).getPackaging();

Renaming

Now the most confusing part. We should consider renaming of the methods and classes

I haven't found proper naming yet but definitely we need something much much shorther.

[ge0ffrey]

+1 on "Keeping Maven related methods out of user's reach" => all this stuff (including when-to-be-offline, which repositories are used when) should be in 100% sync with the build anyway and the shrinkwrap resolver should behave the same (at least on those properties).

+0 on the rest: I don't use the maven resolver directly, because I use the MavenImporter (a facade to the maven resolver). I do have an issue on the importer and I 'll add it to jira.

Great work!

[aslak]

-1 on "Keeping Maven related methods out of user's reach" => There are a number of cases where you want to control these. Maven is in general horrible for defining your test environment, test != build

+1 on "Keeping Maven related methods in sync with Maven build setup by default"

[kpiwko]

By "Keeping Maven related methods out of user's reach" I mean that MavenDependencyResolverWithIntegration, which is the default, won't have these methods... we might allow as(MavenDependencyResolverWithoutIntegration.class) cast if you are sure you need to use different settings.xml than your build, for instance.

The idea is that if you are in sync in with Maven build setup, you shouldn't not interfere with Maven settings at all. If you want to interfere with Maven settings, you should use MavenDependenyResolverWithoutIntegration, where you are required to control everything by yourself. But you won't get anything by default, it is your work to set all that.

[kpiwko]

Modified according to the document above and and IRC discussions on #jbosstesting

New and noteworthy:

• There's a Maven plugin, you can use it to get information about your Maven build in the tests using MavenConfigurationTypes.ENVIRONMENT (surefire 2.9+ required)
• Added configureFrom(MavenConfigurationType), with MavenConfigurationTypes.MANUAL, MavenConfigurationTypes.ENVIRONMENT - it was not possible to implement via enum because they can keep enough information (parameter types) for API to be fluent, however it means you're able to configure your own MavenConfigurationType easily
• configureFrom(String) renamed to loadSettings(String) to be on par with loadEffectiveSettings(String, String...)
• method up() is no longer necessary when working with EffectivePomMavenResolver
• super extra cool Aslak's SHRINWKRAP-366 feature is there...now you can use Maven Reactor or IDE Workspace to retrieve artifacts!
• small improvements on API definition (e.g. removed repetition of methods, add Unsupported exceptions) and a bit more javadoc

Where to get it?

https://github.com/shrinkwrap/resolver/tree/next

We would like you to test it so we can be pretty sure it should be a baseline for 2.0.0 stable release you're all waiting for.

Thanks and onwards!