-
1. Re: Using dependencies from the pom.xml
kpiwko Feb 8, 2012 12:28 PM (in response to mcgin)Hi,
sure, MavenDependencyResolver is able to do that. You can check usage at https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/PomDependenciesUnitTestCase.java and https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/java/org/jboss/shrinkwrap/resolver/impl/maven/PomFilteringUnitTestCase.java , for instance.
To be precise, you're likely interested in one of these:
1/ Reusing versions from pom.xml file
WebArchive war = ShrinkWrap.create(WebArchive.class, name + ".war").addAsLibraries(
DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("target/poms/test-remote-child.xml")
.up().artifact("org.jboss.shrinkwrap.test:test-deps-c").resolveAs(GenericArchive.class));
2/ Importing all dependencies specified in pom.xml
WebArchive war = ShrinkWrap.create(WebArchive.class, name + ".war").addAsLibraries(DependencyResolvers.use(MavenDependencyResolver.class).loadEffectivePom("target/poms/test-child.xml")
.importAllDependencies().resolveAs(JavaArchive.class))
3/ Importing all dependencies and do some filtering
File[] jars = DependencyResolvers
.use(MavenDependencyResolver.class)
.loadEffectivePom("target/poms/test-filter.xml")
.importAnyDependencies(
// this is applied before resolution, e.g. has no information about transitive dependencies
// it means:
// 1. it excludes whole tree of the exclusion
// 2. it does not affect transitive dependencies of other elements
new ExclusionsFilter("org.jboss.shrinkwrap.test:test-deps-a", "org.jboss.shrinkwrap.test:test-deps-c",
"org.jboss.shrinkwrap.test:test-deps-d")).resolveAsFiles();
There's a bunch of filters, you can even pass then to resolveAsFiles(MavenFilter) methods:
-
2. Re: Using dependencies from the pom.xml
julien_viet Oct 10, 2012 6:23 AM (in response to kpiwko)How about having :
DependencyResolvers.use(MavenDependencyResolver.class).useCurrentPom().resolvePomDependency("foo:bar").importAllDependencies()
useCurrentPom() -> resolve the current pom running the test
resolvePomDependency() -> resolve a dependency as another pom
so in a multi project I can have two pom A->B:
- A is where I run test
- B is where I specify the dependencies I want in my package
the goal is to:
- avoid to harcode /target in unit test and deal with those details
- make B part of maven life cycle when release plugin is used
- import only the dependencies from B and not have to deal with exclusion because artifact may be added to A or removed from A which would impact the test
You would make a bunch of people happy and relieved.
-
3. Re: Using dependencies from the pom.xml
alrubinger Oct 10, 2012 11:37 PM (in response to julien_viet)Hey Julian:
Back from JavaOne and PTO, thanks for waiting patiently.
To be sure I'm groking this correctly, you want:
1) To use the "current" POM "A" to resolve a dependency "B" (we have this already)
2) The dependency "B" to be resolved is of packagingType "pom"
3) From that resolved second-level POM "B", resolve some other dependency, "C".
Does this describe the feature request you'd like?
-
4. Re: Using dependencies from the pom.xml
julien_viet Oct 11, 2012 2:14 AM (in response to alrubinger)Hi Andrew,
I will tell you what my use case is:
I need to write unit test with junit in a maven project and package archives containing jars. The maven dependency resolver is the solution to this but what I want to achieve is to have the dependencies to be in a pom and this pom with the constraints:
1/ the pom is managed by the project running the unit test
2/ the pom is not the current pom project because it can contain many dependencies that I don't want and I don't want to filter them. It should be a pom dedicated to this use case
To achieve this the following project structure is used:
1/ two modules A and B children of a parent P (classic)
2/ B contains the dependencies, one important point is that B could contain dependencies to some artifact to the current project with a -SNAPSHOT version
3/ A depends on B so we are sure that B is processed before A
- when the project is released the dependencies will be upgraded correctly in B and the junit test in A does not need to be updated
- the test in A should package the dependencies in B only and nothing more
It would be great to have a way tol achieve this in a trivial manner using ShrinkWrap resolver only.