maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <>
Subject Re: [Maven 4.0.0] Removing ability for plugins to dynamically inject dependencies
Date Sun, 06 Apr 2014 20:47:43 GMT
Op Sun, 06 Apr 2014 20:54:24 +0200 schreef Jason van Zyl <>:

> On Apr 6, 2014, at 2:24 PM, Robert Scholte <> 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  
- 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.


> 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  
>> <>:
>>> 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:
>>> 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
>>> ---------------------------------------------------------
>>> We all have problems. How we deal with them is a measure of our worth.
>>> -- Unknown
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> Thanks,
> Jason
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> ---------------------------------------------------------
> 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:
For additional commands, e-mail:

View raw message