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.

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)

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

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

Tks

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.

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.

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?)