On 7-Mar-09, at 7:27 AM, Benjamin Bentmann wrote:
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?
What I'm looking at in 3.x is that there can N repositories that
partake in the execution of a lifecycle. I see a layering of any
number of local repositories which may include the local repository as
we know it, IDE workspaces and the reactor (which is a workspace of
sorts).
Right now the logic for picking out plugins and artifacts while in a
reactor is a mess. I'm in the middle of refactoring the plugin manager
and lifecycle executor right now but when I'm finished the execution
request, and therefore the session, will contain this layering of
repositories. One of these implementations will be the "reactor
repository". So if you can encapsulate your logic above in a component
then I can just reuse that in the reactor repository. Implement
whatever behavior you initially think is appropriate and once it's all
in one place it's easy to adjust the rules.
I found about a half dozen places where there is weird logic for
dealing with artifacts in the reactor and it needs to be localized to
one component. That can then be incorporated in the changes that Oleg
has made which gives repository implementations some brains about
making decisions and interacting with other repositories.
Just make sure your logic for dealing with the reactor is all in one
place right now and then go for it.
Benjamin
[0] http://svn.eu.apache.org/repos/asf/maven/components/branches/MNG-3043
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Three may keep a secret if two of them are dead.
-- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
