On the XWiki project we wanted to generate custom XWiki WARs directly from our unit tests (to deploy XWiki in Docker containers automatically and directly from the tests).
I was really excited when I discovered the SkrinkWrap Resolver library. It looked exactly to be what I needed. I didn't want to use Aether (now deprecated) or the new Maven Resolver (wasn't sure what the state was and very little doc to use it).
So I coded
( ). Here are some extracts showing you how easy it is to use ShrinkWrap.Example to find all dependencies of an Artifact:
String.format("org.xwiki.platform:xwiki-platform-distribution-war-dependencies:pom:%s", version));
...
protected List<MavenResolvedArtifact> resolveArtifactWithDependencies(String gav)
{
return getConfigurableMavenResolverSystem()
.resolve(gav)
.withTransitivity()
.asList(MavenResolvedArtifact.class);
}
protected ConfigurableMavenResolverSystem getConfigurableMavenResolverSystem()
{
return Maven.configureResolver()
.withClassPathResolution(true)
.withRemoteRepo(
"mavenXWikiSnapshot", "http://nexus.xwiki.org/nexus/content/groups/public-snapshots", "default")
.withRemoteRepo(
"mavenXWiki", "http://nexus.xwiki.org/nexus/content/groups/public", "default");
}
Here's another example to read the version from a resolved pom.xml file (didn't find how to do that easily with Maven Resolver BTW):
{
MavenResolverSystem system = Maven.resolver();
system.loadPomFromFile("pom.xml");
// Hack around a bit to get to the internal Maven Model object
ParsedPomFile parsedPom = ((MavenWorkingSessionContainer) system).getMavenWorkingSession().getParsedPomFile();
return parsedPom.getVersion();
}
And here's how to resolve a single Artifact:
String.format("org.xwiki.platform:xwiki-platform-tool-configuration-resources:%s", version));
...
protected File resolveArtifact(String gav)
{
return getConfigurableMavenResolverSystem()
.resolve(gav)
.withoutTransitivity()
.asSingleFile();
}
Pretty nice, isn't it?
It looked nice till I tried to use the generated WAR... Then, all my hopes disappeared... There's one big issue: it seems that ShrinkWrap will resolve dependencies by using a strategy different than what Maven does:
- Maven: Maven takes the artifact closest to the top (From the Maven web site: "Dependency mediation - this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the "nearest definition" which means that it will use the version of the closest dependency to your project in the tree of dependencies.").
- ShrinkWrap: First artifact found in the tree (navigating each dependency node to the deepest).
So this led to a non-functional XWiki WAR with completely different JAR versions than what is generated by our Maven build.
To this day, I still don't know if that's a known bug and since nobody was replying to my thread on the ShrinkWrap forum I created an issue to track it. So far no answer. I hope someone from the ShrinkWrap project will reply.
Conclusion: Time to use the Maven Resolver library... Spoiler: I've succeeded in doing the same thing with it (and I get the same result as with mvn on the command line) and I'll report that in a blog post soon.