Hi,
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?
Benjamin
[0] http://svn.eu.apache.org/repos/asf/maven/components/branches/MNG-3043
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
