maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bentmann <>
Subject MNG-3043, please comment
Date Sat, 07 Mar 2009 15:27:55 GMT

Dependency resolution from the reactor is currently rather limited to 
artifacts that have already been assembled. E.g. running "mvn test" 
can't resolve a test JAR of another module from the reactor because this 
JAR has yet to be assembled during the "package" phase (see demo project 
attached to MNG-3043). The same applies for running "mvn compile" and a 
dependency on another module's EJB client JAR. The latter scenario was 
reported in MNG-2871 for which already a patch has been applied to 3.x.

The solution [0] I propose additionally solves MNG-3043 and would 
supercede the current approach for MNG-2871. Essentially, 
MavenProject.replaceWithActiveArtifact() will fallback to either the 
main or test output directory in case no real artifact has been 
assembled/attached so far.

The implementation is based on a new artifact class 
ActiveProjectOutputArtifact whose getFile() returns either the project's 
main or test output directory dependending on the type/classifier of the 
artifact being wrapped.

This approach provides a best effort to resolve class path dependencies 
from information given in the POM for build phase prior to "package". Of 
course, loose class files and assembled JARs are not always equivalent 
so a modified version of the warning John introduced for MNG-3023 will 
ensure the user knows about that.

The patch expectedly/intentioally breaks the current ITs testitMNG3023A 
and testitMNG3023C which test for dependency resolution failure or 
fallback to the repository, respectively.

If nobody has objections to this approach or sees severe dangers with 
it, I would like to apply this to 2.1.x and 3.x. WDYT?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message