On Apr 6, 2014, at 2:24 PM, Robert Scholte <rfscho...@apache.org> wrote:
> Hi, > > if we are talking about immutable classpath I agree. But there's something > else which needs to be improved. > Let me describe it with the maven-javadoc-plugin, but there are more plugins > suffering the same problem. > You must be able to specify doclettags artifact. There are dependencies, but > they are not added to the classpath. These jars are added to a different > argument of the javadoc executable. > So the generic category is the downloading of artifacts that are passed into the command line of an executable? So the plugin already has a dependencies element but the javadoc plugin has a special element such that you can get hold of these dependencies to feed into the command line. Yes? I believe we can make this generic and prevent plugins from having to do their own resolution logic. > I see two solutions: > - mark these fields in the plugin as being dependencies, which must be > resolved. > - add a custom field to the plugin-dependency in the pom.xml, so the plugin > knows which dependencies are used for which purpose. > > With both solutions it should also be possible for the maven-release-plugin > to verify all used dependencies, which is impossible right now. > The think the second would be better. We already have a <dependencies/> element which are added to the classpath of the executing plugin, but another element like, say, <artifacts/> can just be downloaded and injected into the plugin such that it can do what it likes with the files of the downloaded artifacts. Would this satisfy the requirement of the javadoc plugin? Striving for plugins not having to specify and resolution is the goal and this would certainly help. If we stepped through all the plugins that we know of which employ their own resolution logic we can push it back into the core. This also eliminates having to expose most of the resolution system which would go a long way in not having to expose Aether. Being purely declarative, as we should, is best. It's just sort of slipped in many places because we let people get at the resolution internals. Ultimately this means that what gets exposed is a very simple Artifact-like entity and a simple graph for things like the dependency plugin and enforcer and we eliminate exposing the underbelly of resolution which is a huge problem right now. Also if the artifact-like entity had actions that could be attached then very sophisticated things like what the Android people need would not require using the resolution system at all. Not sure how many people are familiar with p2 but it has the notion of actions that are associated with artifacts. So you might say I want this artifact downloaded, unpack it, and add this directory in the unpacked structure to my classpath. It would be a radical simplification to basically shear off all access to the resolution system. If we had this years ago we would not have these problems we have with the switches between Maven Artifact, Sonatype Aether, and Eclipse Aether. This means that many plugins need to be remade but they will be far simpler. For Maven 4.0.0 I say go big, go simple, or go home. I've been noodling around for a couple months and there are a few simple mistakes we made in the past and they have bloomed into relatively large problems. I think they are all fixable provided we just bite the bullet and start removing the janky code. (I can't seem to edit anything in Confluence or I would have written more there) > thanks, > > Robert > > > Op Sun, 06 Apr 2014 15:55:07 +0200 schreef Jason van Zyl <ja...@takari.io>: > >> 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. >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> http://twitter.com/takari_io >> --------------------------------------------------------- >> >> We all have problems. How we deal with them is a measure of our worth. >> >> -- Unknown >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
