https://cwiki.apache.org/confluence/display/MAVEN/Resolution+scenarios+for+plugins
On Apr 6, 2014, at 4:47 PM, Robert Scholte <rfscho...@apache.org> wrote: > Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl <ja...@takari.io>: > >> >> 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? > > I think this will work. A quick look at the javadoc plugin shows me the > following <artifacts/>: > - additionalDependencies: capability to add optionnal dependencies to the > javadoc classpath. > - bootclasspathArtifacts: Specifies the artifacts where the boot classes > reside. > - docletArtifacts: Specifies multiple artifacts containing the path for the > doclet starting class file (specified with the -doclet option). > - resourcesArtifacts: A list of artifacts containing resources which should > be copied into the Javadoc output directory (like stylesheets, icons, etc.). > - tagletArtifacts: Specifies several Taglet artifacts containing the taglet > class files (.class). These taglets class names will be auto-detect and so no > need to specify them. > > These are artifacts which must be downloaded, and they are all specified as > groupId/artifactId/version. I don't see additional elements, but we need to > investigate other plugins as well. > > Maybe worth a separate wiki page. > > thanks, > Robert > > >> >> 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 >> >> >> >> >> >> >> >> > > --------------------------------------------------------------------- > 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 --------------------------------------------------------- We know what we are, but know not what we may be. -- Shakespeare
