[ https://issues.jboss.org/browse/SHRINKWRAP-397?page=com.atlassian.jira.pl... ] Craig Ringer updated SHRINKWRAP-397: ------------------------------------ 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. 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 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 Forum Reference: https://community.jboss.org/message/729492 (was: https://community.jboss.org/message/729492) -- 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

[ https://issues.jboss.org/browse/SHRINKWRAP-397?page=com.atlassian.jira.pl... ] Craig Ringer updated SHRINKWRAP-397: ------------------------------------ Attachment: ArquillianShrinkwrapImportPom-2.0.0-alpha-1.zip Test case against 2.0.0-alpha-1 -- 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

[ https://issues.jboss.org/browse/SHRINKWRAP-397?page=com.atlassian.jira.pl... ] Craig Ringer updated SHRINKWRAP-397: ------------------------------------ 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". 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 &lt;type&gt;import&lt;/type&gt; 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 . This can't wholly replace specification by artifact co-ordinates, as not all artifacts necessarily contain Java classes, and it may also be desirable to bundle artifacts that aren't in <test/> scope so their classes can't be referenced directly in the tests. 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 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. 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 &lt;type&gt;import&lt;/type&gt; 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 Forum Reference: https://community.jboss.org/message/729492 (was: https://community.jboss.org/message/729492) -- 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

[ https://issues.jboss.org/browse/SHRINKWRAP-397?page=com.atlassian.jira.pl... ] Martin Kouba commented on SHRINKWRAP-397: ----------------------------------------- Hi Craig, your test is not using 2.0.0-alpha-1 but 1.0.0-beta-5 specified in Arquillian's BOM. Specify the shrinkwrap-resolver-impl-maven dependency in order to override BOM. {code} <dependency> <groupId>org.jboss.shrinkwrap.resolver</groupId> <artifactId>shrinkwrap-resolver-impl-maven</artifactId> <version>2.0.0-alpha-1</version> <scope>test</scope> </dependency> {code} In 2.0.0-alpha-1 you can use {{EffectivePomMavenDependencyResolver}} to omit versions which are already present in the POM file. {code} DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("pom.xml").artifact("org.apache.commons:commons-lang3").resolveAsFiles(); {code} -- 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