Feature Gap between SWR 1.x and 2.0.0-alpha-2?

[alrubinger]

Craig Ringer notes the following:

In Alpha1 I could write:

private final EffectivePomMavenDependencyResolver resolver =
DependencyResolvers.use(MavenDependencyResolver.class)
.loadEffectivePom(“pom.xml”);

private final MavenDependencyBuilder depBuilder = resolver.artifacts();

then add artifacts with `depBuilder.artifacts(“blah:blah”)` to accumulate them.

In Alpha2 this no longer seems to be possible. It looks like I’ll have to accumulate a list of artifact co-ordinates then pass them to one big resolve() call, or do individual transitive resolutions and build a File[] array. If I do multiple resolutions I’m likely to land up with poor transitive resolution and conflicts, so I’ll probably need to accumulate the artifacts.

I'm not quite grokking the disconnect, however.  How is using one resolve call with N coordinates in "alpha-2" any different from the earlier method of using a MavenDependencyBuilder and adding artifacts to it?

S,

ALR

[ringerc]

It was between SWR 2.0.0-alpha-1 and SWR 2.0.0-alpha-2 that I noticed the change, but I didn't make that properly clear. In functionality terms it doesn't land up making any difference; I can accumulate the artifacts in a Set<String> then pass them to the Resolver like this:

// Member var:
Set<String> artifacts = new HashSet<String>();

// then with `artifacts' populated:
MavenResolverSystem resolver = Maven.configureResolver().fromFile("pom.xml");
WebArchive a = ShrinkWrap.create(WebArchive.class);
a.addAsLibraries(resolver.resolve(artifacts.toArray(new String[artifacts.size()])).withTransitivity().as(File.class));

and that's probably the right thing to do anyway. There's no reason SWR should have to accumulate the artifacts for me, I was just initially surprised to have lost that ability. I wouldn't normally have posted that, but yesterday was an extremely exhausting day where I started off tired, so I had the mental capacity of a stoned cricket.

A `resolver.resolve(Collection<String>)` would be nice, as the current API is very much written with a single fluent in-line use where everything's a literal. That's fine for many use cases, but makes it annoying to write helper classes that're shared between many tests, where you want to add artifacts, descriptors, etc for different chunks of the application depending on what you're testing.

The more serious issue I encountered was that:

Maven.configureResolver().fromFile("pom.xml").resolve("commons-collections:commons-collections").withTransitivity().as(File.class);

fails, complaining that it cannot resolve a version for commons-collections:commons-collections, even though it's declared as a dependency in pom.xml and was resolved fine by resolvers 2a1.

[alrubinger]

Craig Ringer wrote:

Maven.configureResolver().fromFile("pom.xml").resolve("commons-collections:commons-collections").withTransitivity().as(File.class); 

fails, complaining that it cannot resolve a version for commons-collections:commons-collections, even though it's declared as a dependency in pom.xml and was resolved fine by resolvers 2a1.

We *do* have tests for this:

  https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/integration/PomDependenciesUnitTestCase.java#L112

I think your problem here is that you're trying to "configure" from a pom.xml.  Instead, "configureFrom" applies to "settings.xml"  We've changed the wording a bit.  What you want is:

Maven.resolver().loadPomFromFile()

You can also load from a ClassLoader resource.

I've opened a JIRA to throw some RuntimeException if you pass a POM format file into a "configureFrom" method: https://issues.jboss.org/browse/SHRINKRES-72

Does that solve the issue for you?

[alrubinger]

FYI, accepting Collection<String> in "resolve" and Collection<MavenDependency> in "addDependencies" will be supported starting in 2.0.0-alpha-5:

  https://issues.jboss.org/browse/SHRINKRES-66

   https://github.com/shrinkwrap/resolver/commit/908b0c3e9e1723fc983d5782b6c316d539000b34

Thanks for bringing this issue to our attention.

S,

ALR

[atiyou]

Hi,

As the new version of shrinkwrap resolver "2.0.0-alpha-4", i collect my jar files like this :

File[] libs = Maven.resolver().loadPomFromFile("pom.xml").resolve

                 ("ch.qos.logback:logback-core",

                         "ch.qos.logback:logback-classic").

                 withTransitivity().as(File.class);

But i want to merge them with a JavaArchive not WebArchive, So how can i do it ?

jar.addAsLibraries(libs).as(JavaArchive.class); (doesn't exist)

[alrubinger]

Java archives don't have a spec-defined "lib" directory, so "addAsLibrary" wouldn't make sense there like it does for WebArchive (which puts the arguments into WEB-INF/lib).

You could simply use JavaArchive.add() and give the desired path?  Or put in the root?

[alrubinger]

PS - I'll kindly ask further user questions be directed to our User Forum.  It'll help t okeep these existing Development discussions focused.

[atiyou]

No problem, i got your answer on the other side...

I was really stuck and i didn't find a answer elswhere

Tks

[ringerc]

Just back from holidays. I'll check and see, but it sounds right.

An error certainly should be thrown if it's expecting <settings/> and it gets <project/> or vice versa, especially with method names that don't use FromPomXml or FromSettingsXml or anything like that.

[alrubinger]

Cool.  I'd also hoped, with regards to naming, that "configureResolver().fromFile()" would be clear that you're configuring from settings.  While "loadPomFromFile" and "loadPomFromClassLoaderResource" should be pretty clear.

Open to renaming if we've got better suggestions on the table; we're still in Alpha for this very reason.

S,

ALR

[ringerc]

It probably is to sensible people; to me it seemed that one might reasonably "configure" the resolver from a pom, populating it with knowledge about dependencies and versions.

[ringerc]

Back from an extended break + other business.

I can confirm that using the API correctly fixes the issue ;-)

    WebArchive a = ShrinkWrap.create(WebArchive.class);
        a.addAsLibraries(
            Maven.resolver().loadPomFromFile("pom.xml")
            .resolve(artifacts.toArray(new String[artifacts.size()])).withTransitivity().as(File.class));

where artifacts is a List<String>.

I'm having issues convincing it to read dependency versions from pom.xml where the dependency is declared <scope>runtime</scope>. That's easily enough worked around by first declaring the dependency without a scope in <dependencyManagement/> then referencing it with a scope override in <dependencies/> though.

(Wonder if a preview will ever be added to this forum editor?)

[alrubinger]

Craig Ringer wrote:

I'm having issues convincing it to read dependency versions from pom.xml where the dependency is declared <scope>runtime</scope>. That's easily enough worked around by first declaring the dependency without a scope in <dependencyManagement/> then referencing it with a scope override in <dependencies/> though.

Isn't that the expected behavior, as "runtime" scope is not transitive?

Or this is from a direct dependency declaration in the POM, where the version is provided?

S,

ALR