Importing dependencies automatically

discussion
api

#1

One thing that you usually need to do when using Arquillian for testing is add some common dependencies to the microdeployment generated by Shrinkwrap. Basically what you do is using Maven resolver to get dependencies and add it as library.

That’s good but the problem is that sometimes there are some libraries that are always added, and you need to repeat the same over and over again. One example of these libraries might be Configuration/Utils APIs like Apache Tamaya or DeltaSpike. And this problem is faced in Wildfly Swarm where they are adding automatically all the dependencies form pom automatically.

But we could generalize this into an extension which it reads pom.xml and by default adds all the dependencies that are of scope compile. We could add configuration parameters for excluding some artifacts, add dependencies of different scopes or build file location.

Also this extension would be able to detect if there is a pom.xml or build.gradle and resolve the dependencies accordantly.

So if this is done, Wildfly Swarm would be able to use it and fix the problem of running Arquillian with Gradle at the same time.

WDYT?


#2

Hi @lordofthejars,
technically, the functionality of adding specific dependencies of some scope(s) from a pom.xml file is already implemented. It is also possible to filter them. It is part of my proposal of the new MavenImporter API. https://github.com/shrinkwrap/resolver/pull/102
ShrinkWrap .create(ArchiveMavenAssembler.class) .usingPom("pom.xml") .withDependencies(ScopeType.COMPILE) .as(WebArchive.class);
Is it what you expect?


#3

Well I would expect something like:

ShrinkWrap.create(WebArchive.class)
     .addClasses(A.class, B.class)
     .addAsLibraries(
         Maven.resolver()
           .resolve(ScopeType.COMPILE)
           .loadFromPom("pom.xml").withTransitive().asFile()
     ) .....

WDYT?


#4

Well, It looks good. It will need a lot of refactoring, but with the current implementation it should be feasible…

Thinking about the Resolver. When I take into account the EmbeddedMaven and if this functionality (of fetching dependencies) was added to Maven.resolver(), do we still need the new MavenImporter (ArchiveMavenAssembler) then? Or do we need the MavenImporter in general?


#5

I realized that there is already this functionality implemented in Resolver:

Maven .resolver() .loadPomFromFile("pom.xml") .importCompileAndRuntimeDependencies() .resolve() .withTransitivity() .asFile();
you can also use method .importDependencies(ScopeType.COMPILE)
see: PomEquippedResolveStageBase.html


#6

In practice, when importing everything in @Deployment, users want to have not only maven dependencies but also application artifacts like properties files and descriptors like faces-config, web.xml etc…

So what I’m doing in these cases (usually in legacy applications starting to use Arquillian where creating @Deployment can be very frustrating) I’m building application before tests and using the war file from /target in @Deployment. I’ve described it here: https://rpestano.wordpress.com/2015/11/12/the-simplest-micro-deployment-arqtip-2/


#7

This before-building process can be done automatically directly from your code - what you need to use is the new feature of ShrinkWrap Resolver called EmbeddedMaven. see here: http://arquillian.org/blog/2016/12/01/resolver-3-0-0-alpha-2/