[shrinkwrap-issues] [JBoss JIRA] (SHRINKWRAP-397) ShrinkWrap fails to resolve artifact co-ordinate with version implicit from loaded pom

[Craig Ringer (JIRA)]

     [ https://issues.jboss.org/browse/SHRINKWRAP-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Craig Ringer updated SHRINKWRAP-397:
------------------------------------

    Affects Version/s: 1.0.0
          Description: 
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".

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

Possibly related to https://issues.jboss.org/browse/ARQ-412

  was:
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.

This:

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());

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:

WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war")
    .addPackage(Demo.class.getPackage())
    .addAsLibraries(resolver.artifacts("some-group:some-artifact").resolveAsFiles());


... 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:

WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war")
    .addPackage(Demo.class.getPackage())
    .addAsLibraries(resolver.artifactsFromClasses(org.apache.commons.lang3.ObjectUtils.class).resolveAsFiles());

as suggested in https://issues.jboss.org/browse/ARQ-412

Possibly related to https://issues.jboss.org/browse/ARQ-412

      Forum Reference: https://community.jboss.org/message/729492  (was: https://community.jboss.org/message/729492)


Add specific verions, re-test with latest release
                
> 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, maven, resolver, shrinkwrap
>
> 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".
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira