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" <ljnel...@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 >
