I think allowing plugins to resolve things with annotations is not a good idea as we already have project dependencies resolution that happens on the fly per project. This means it's impossible to fully reason about the requirements of a project being built up front. This, in practice, leads to users building, getting a resolution error, building, getting a resolution error. While not problems can be determined from up-front analysis most of them can. I am more in favor of going the other direction where we have something purely declarative, all dependencies for the project and plugins can be reasoned about up-front and reported to the user for correction.
Ultimately I would like to get rid of on-the-fly resolution and replace it with a stage in Maven's execution that occurs before the build starts. On Apr 12, 2014, at 8:07 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > after thinking more at it, it seems the "scope" for such artifacts is the > plugin parameter name > > so why not resolve artifacts (or collections of artifacts) when injecting > parameters? > I'm not sure we really need a need elemen in pom. > > Regards, > > Hervé > > Le samedi 12 avril 2014 10:14:51 Robert Scholte a écrit : >> Op Fri, 11 Apr 2014 23:50:54 +0200 schreef Benson Margulies >> >> <bimargul...@gmail.com>: >>> On Fri, Apr 11, 2014 at 5:29 PM, Stephen Connolly >>> >>> <stephen.alan.conno...@gmail.com> wrote: >>>> On 11 April 2014 22:10, Benson Margulies <bimargul...@gmail.com> wrote: >>>>>> Fwiw, I don't recall the dependency plugin actually injecting stuff >>>>> >>>>> into >>>>> >>>>>> the project class path but equally wish that the copy/unpack goals >>>>> >>>>> could >>>>> >>>>>> simply go away regardless. (in leu of the more normal >>>>> >>>>> xxx-dependencies >>>>> >>>>>> versions) >>>>> >>>>> If you make them go away, please find them a new home. I use them >>>>> constantly to unpack data resources retrieved from a Maven repo. It >>>>> seems odd that they live in a 'dependency' plugin, but it would be a >>>>> disaster if they disappeared. >>>> >>>> You should be declaring the resources you are unpacking/copying as >>>> dependencies and then using the copy-dependencies or unpack-dependencies >>>> goal instead of the copy or unpack goal. >>> >>> I don't want them in the classpath. Even if their filenames end in >>> '.jar'. >> >> The current proposal is to add an artifacts-element[1] to the plugin. >> Dependencies are for the classpath, artifacts are additional files which >> must be resolved, but don't belong on the classpath. >> >> Robert >> >> [1] >> https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+p >> lugins >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
