I wasn't sure if this came out correctly in the above observations - using a class-member DocumentBuildFactory and XPathFactory, and compiled XPath expressions did not improve performance as much as I liked. This is more so because XPath expression evaluation is expensive, and when repeated across large number of invocations, the use of a compiled expression does not help a lot. Now, given that most of these lookups are duplicates, we need to find some way to cache the results, or we need to prevent the invocations with the duplicate artifacts.

Also, if we would solve this with a cache, we need to ensure that the cache would be re-used across tests, since it would help immensely when multiple @Deployments in different tests use the same Maven artifact.

To be tracked as https://issues.jboss.org/browse/SHRINKRES-37

Another possible optimalization that came to mind is, in the case where you're not resolving trasitive deps:

We could start by by-passing the Aether lib all togather(not even initialize anything from it) and do a simple check if the artifact exist in the local repo, if it does simply return that File. If it doesn't exist, or you're resolving transitive deps, fall back to use Aether.

In theory we would only need to run Aether the first time you depend on a non existing Artifact to have it download, all the following runs on the same machine will simple just resolve GAV to File via Path concats.

To speed up transitive deps, we could cache the resolved GAVs for a specific Artifact combination. No cache hit, fall back to Aether, cache hit found, do a simple GAV to File resolve.

Vineet Reynolds wrote:

 

Also, if we would solve this with a cache, we need to ensure that the cache would be re-used across tests, since it would help immensely when multiple @Deployments in different tests use the same Maven artifact.

This is good point - and good use case for arquillian core - I use caching in form of serialized objects in Drone reusable webdriver sessions - when it would be part of core, all projects can cache through unified interface.

I've performed a few optimizations of ClasspathWorkspaceReader.

• Already mentioned reuse of DocumentBuilder and XPath
• XPath query compilation to XPathExpression
• Retrieved from classpath artifacts caching
• Reduction of number of disk operations (every classpath entry for every retrieved artifact performed disk isFile/isDirectory operations + same thing for found pom files)

I've performed tests basing on forge core\javaee-impl\pom.xml (136 retrieved dependencies). Before changes on my PC running

Maven.resolver().loadPomFromFile(pom).importRuntimeDependencies().asFile();

 

took about 32s. After mentioned optimizations ~1,5s.

Code is available here: https://github.com/shrinkwrap/resolver/pull/35