]
Craig Ringer updated SHRINKWRAP-397:
------------------------------------
Attachment: ArquillianShrinkwrapImportPom-2.0.0-alpha-1.zip
Test case against 2.0.0-alpha-1
ShrinkWrap fails to resolve artifact co-ordinate with version
implicit from loaded pom
--------------------------------------------------------------------------------------
Key: SHRINKWRAP-397
URL:
https://issues.jboss.org/browse/SHRINKWRAP-397
Project: ShrinkWrap
Issue Type: Bug
Components: ext-resolver
Affects Versions: 1.0.0
Environment: JBoss AS 7.1.1.Final
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)
Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Reporter: Craig Ringer
Labels: arquillian, dependencies, maven, resolver, shrinkwrap
Attachments: ArquillianShrinkwrapImportPom-2.0.0-alpha-1.zip
ShrinkWrap's Maven Dependency Resolver doesn't successfully resolve artifacts
that're specified with an implicit version in their co-ordinates, even if that version
can be determined from a loaded pom.xml . This forces duplication of version listings
between tests and the project pom, leading to greater maintenance burden and the increased
probability of tests not reflecting the real code that gets run.
Tested with
"org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven:jar:1.0.0-beta-6"
as depended on by Arquillian 1.0.0.Final via
"org.jboss.shrinkwrap:shrinkwrap-impl-base:jar:1.0.0". Re-tested with resolver
2.0.0-alpha-1, issue remains.
This:
{code}
MavenDependencyResolver resolver =
DependencyResolvers.use(MavenDependencyResolver.class)
.configureFrom("pom.xml");
WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war")
.addPackage(Demo.class.getPackage())
.addAsLibraries(resolver.artifacts("some-group:some-artifact:1.0.0.Final").resolveAsFiles());
{code}
should, if some-group:some-artifact is defined in pom.xml via a direct dependency,
dependencyManagement section, parent pom, or a
<type>import</type> pom in dependencyManagement, then it
should be able to figure out the version without it being specified, eg:
{code}
WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war")
.addPackage(Demo.class.getPackage())
.addAsLibraries(resolver.artifacts("some-group:some-artifact").resolveAsFiles());
{code}
... or even better, the artifact should be resolved from a class reference by looking up
the artifact, so you can write something like the imaginary:
{code}
WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war")
.addPackage(Demo.class.getPackage())
.addAsLibraries(resolver.artifactsFromClasses(org.apache.commons.lang3.ObjectUtils.class).resolveAsFiles());
{code}
as suggested in
https://issues.jboss.org/browse/ARQ-412
Note that importing dependencies from the target's pom wholesale succeeds, but offers
no control over which dependencies are pulled in so you can't test with a subset, a
particular profile, etc.
{code}
resolver.includeDependenciesFromPom("pom.xml");
{code}
Possibly related to
https://issues.jboss.org/browse/ARQ-412
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: