The class MavenResolvedArtifactImpl will try to resolve mvn artifacts. This works well since 2.2.5, for jar and test dependencies.

For war dependencies this is still problematic though. The code looks like this:

// SHRINKRES-102, allow test classes to be packaged as well
File root = new File(artifact.getFile().getParentFile(), "target/classes");
if (!Validate.isNullOrEmpty(classifier) && "tests".equals(classifier)) {
  root = new File(artifact.getFile().getParentFile(), "target/test-classes");
}

In other words, it will locate the pom, say foo/bar/pom.xml, and from there try to resolve ../target/classes or ../target/test-classes for tests.

In case the pom has <packaging>war</packaging> this is not sufficient however. The Maven war plugin creates its output in ../target/$project.artifactId-$project.version.

So if the Shrinkwrap resolver is used to resolve a .war, it will create a .war file with the wrong contents. This can be demonstrated for JavaEE with the beans.xml resource.

Test setup:
A WAR project, with a beans.xml resource located at src/main/resources/META-INF/beans.xml

Current behaviour:
Shrinkwrap will build a .war file with the contents of ../target/classes, so the beans.xml is added as META-INF/beans.xml inside the .war. This is the wrong location.

Correct behaviour:
Shrinkwrap should look for a ../target/$project.artifactId-$project.version directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the beans.xml is added as WEB-INF/classes/META-INF/beans.xml.