Install hack

[Laird Nelson <lj...@gmail.com>]

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

Re: Install hack

[Stephen Connolly <st...@gmail.com>]

On 19 June 2013 22:31, Laird Nelson <lj...@gmail.com> wrote:

> On Wed, Jun 19, 2013 at 2:14 PM, Thomas Broyer <t....@gmail.com> wrote:
>
> > With copy, you declare the needed artifact in the plugin configuration.
> > From Maven's PoV there's no dependency between the module that copies and
> > one being copied.
>
>
> Right.  OK.
>
>
> > That means Maven can choose to build those two modules in
> > any order.
>
>
> Sure.  Oh, I see; I would have thought this would be obvious.
>

Yes but loads of people prefer to blame maven rather than their own actions.

On re-reading that post of mine I do agree that there are a lot of layers
of information... I think the first layer does its job... and the
subtleties are there to entertain those who want to learn more about Maven


>
>
> > If copied is built before copier, all is well, copied will be
> > resolved from the reactor. However, if copier is built first, it'll pick
> > copied from the local cache (or remote repo) and won't have the proper
> > version/content (assuming SNAPSHOT, of course).
> >
>
> I see.
>
>
> > All of this us avoided with copy-dependencies, because it uses the
> module's
> > dependencies, so copier *depends* on copied and they'll always be built
> in
> > the correct order.
> >
>
> Nice; thanks for the clarification.
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>

Re: Install hack

[Laird Nelson <lj...@gmail.com>]

On Wed, Jun 19, 2013 at 2:14 PM, Thomas Broyer <t....@gmail.com> wrote:

> With copy, you declare the needed artifact in the plugin configuration.
> From Maven's PoV there's no dependency between the module that copies and
> one being copied.


Right.  OK.


> That means Maven can choose to build those two modules in
> any order.


Sure.  Oh, I see; I would have thought this would be obvious.


> If copied is built before copier, all is well, copied will be
> resolved from the reactor. However, if copier is built first, it'll pick
> copied from the local cache (or remote repo) and won't have the proper
> version/content (assuming SNAPSHOT, of course).
>

I see.


> All of this us avoided with copy-dependencies, because it uses the module's
> dependencies, so copier *depends* on copied and they'll always be built in
> the correct order.
>

Nice; thanks for the clarification.

Best,
Laird

-- 
http://about.me/lairdnelson

Re: Install hack

[Thomas Broyer <t....@gmail.com>]

The difference between copy and copy-dependencies on the example is not
about the plugin, but about the reactor.

With copy, you declare the needed artifact in the plugin configuration.
>From Maven's PoV there's no dependency between the module that copies and
one being copied. That means Maven can choose to build those two modules in
any order. If copied is built before copier, all is well, copied will be
resolved from the reactor. However, if copier is built first, it'll pick
copied from the local cache (or remote repo) and won't have the proper
version/content (assuming SNAPSHOT, of course).
All of this us avoided with copy-dependencies, because it uses the module's
dependencies, so copier *depends* on copied and they'll always be built in
the correct order.
Le 19 juin 2013 21:24, "Laird Nelson" <lj...@gmail.com> a écrit :

> 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
>