Jason van Zyl wrote: > On Apr 7, 2014, at 3:19 AM, Jörg Schaible <joerg.schai...@swisspost.com> > wrote: > >> Hi Jason, >> >> Jason van Zyl wrote: >> >>> >>> If everyone agrees we can start systematically documenting what has been >>> removed, as we have lost track of this accurately in the past. I'd like >>> to make a 4.x branch in 4 weeks or so and this will be one of the first >>> things I'd like to cut. It will be one of those radical simplifications >>> that will start allowing people to get a better understanding of the >>> core as I can put the resolution logic in one place as it is currently >>> in many. >> >> Do you only mean injecting new dependencies into the classpath or >> injecting new ones into the reactor that will have to be considered for >> dependency resolution? MNG-4363 talks of the former, your proposal seems >> to include the latter. >> > > My proposal is strictly to prohibit a plugin from modifying a project's > classpath implicitly. That this become fully explicit such that I can > remove some of the convoluted logic in the core to account for this. > >> How do you then intent to resolve dynamically dependencies with different >> classifiers? >> >> The dependency plugin does this explicitly for its sources and javadoc >> goals (resolving artifacts with corresponding classifier). The site >> plugin does it implicitly with an artifact having a "site" classifier. >> And we have developed an own plugin doing the same to aggregate >> documentation from the dependencies. >> >> It does not make sense for these cases to declare those artifacts with a >> (different) classifier. What about this scenario? >> > > I'm not exactly sure what your question is. Do you mean how would you > accomplish these types of tasks without using the resolver directly and do > this declaratively?
No, the plugin should use the resolver and a user should not have to declare such artifacts as dependencies ... just as it is now. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
