Hi Jason, Jason van Zyl wrote:
> Hi, > > I started making of list of things I'd like to remove in Maven 4.0.0, but > I would like to start getting some agreement on what we can yank and this > is the first concrete request. I would like to remove the ability for > plugins to magically inject dependencies. Plugins can either declare their > dependencies or instruct users to add dependencies to the plugins in their > POMs. This weird logic for plugins to add dependencies dynamically is the > cause of some extremely convoluted logic in the resolution code and I want > to remove it. > > The original issue is here: http://jira.codehaus.org/browse/MNG-4363 > > I encountered this when trying to hoist all the resolution logic into once > place so that from our Aether provider resolution as it is done in the > core can be done everywhere. Right now we have plugins like the assembly > plugin, WAR plugin, dependency plugin that all do their own weird, > inconsistent thing and when I tried to put it all in one place so that it > can be analyzed, optimized and then executed this issue cropped up. We > never should have allowed this in the first place but carried it over from > 2.x for compatibilities sake. This might affect the code coverage tools > but we can find a cleaner way. This logic is totally bizarro and needs to > go. > > 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. 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? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
