maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Laird Nelson <ljnel...@gmail.com>
Subject Install hack
Date Wed, 19 Jun 2013 19:23:56 GMT
I'm reading http://developer-blog.cloudbees.com/2012/12/maven-and-hack.htmlagain.
 I have this feeling it has a lot more information in it than I am
able to parse out of it.

I certainly get the basic gist: it is a warning to plugin developers and
users everywhere to remember that you're supposed to resolve artifacts from
the reactor first, the local cache second, and any remote repositories
last.  So I understand the basic gist about how "mvn install" is a hack: if
you have broken plugins that don't respect this order--most notably ones
that do not consult the reactor--then sometimes you have to "seed" the
local cache with the right version of a given artifact to be used later on
in the build.

But then there's a section that reads like this:

You can have even more fun, for example when people use goals like
dependency:copy<http://maven.apache.org/plugins/maven-dependency-plugin/copy-mojo.html>
to
pull artifacts which are produced from the reactor rather than adding a
dependency to the module and using
dependency:copy-dependencies<http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html>…
this results in a situation where you have hidden inter-module dependencies
from Maven so it cannot sequence the reactor correctly and Maven must now
act like a Rabbit<http://answers.yahoo.com/question/index?qid=20080301130057AA1MHtI>…
not a pleasant prospect.


What is this trying to say?  My translation is something like this:

dependency:copy copies artifacts from the reactor, not from the local cache
(the local Maven repository), and this is bad for some unspecified reasons.
dependency:copy-dependencies on the other hand follows the proper artifact
resolution order of reactor, local cache, remote repository and this is
good, even when the dependency in question comes from the reactor (in which
case it behaves exactly the same as dependency:copy).  If you use the first
one to attempt to "solve" some sort of dependency problem, you are in for a
world of trouble.  Using the second one is also bad in some sort of
unspecified way, but not as bad as the first one.


Is that right?  I'm quite sure it's not. :-)

Is the recommendation in this paragraph to prefer
dependency:copy-dependencies because it follows the proper artifact
resolution algorithm?  Put another way: why is the maven-dependency-plugin
even mentioned in here?  Is it part and parcel of solving the install hack?
 Does it brute force dependency resolution in some way that can be picked
up by other downstream "bad" plugins?

I know that Maven 1 had a reactor concept in it that was made very
explicit.  I also know that after about Maven 2.1 that concept disappeared
underground and is no longer present in the command line tools or
documentation, but that people still talk about it.  I am trying to get our
build into a state where we do not rely on the install hack.  Any further
clarification here is welcomed gratefully.

Best,
Laird

-- 
http://about.me/lairdnelson

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message