maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Question about dependency classloading in plugin
Date Tue, 28 Dec 2004 23:04:27 GMT
It's a huge pain in the butt - but you can't (yet). Plugin separation of 
the classloaders has been on the cards for a long while, but when I 
implemented it in pre-1.0 I found a large number of projects started 
breaking because they had come to depend on plugin's dependencies being 
present :)

It may be available in 1.1, and definitely is in 2.0.

Plugins should always aim for the lowest common denominator dependency 
in this case. 3.0 for collections is still quite high.

If it is just the one class, and it doesn't have any dependencies on 
other collections classes, I'd strongly suggest copying the class from 
commons-collections into a different package in the plugin. This is ok 
legally due to the ASF 2 license on both, and we can take a note that 
the collections dependency can be added back later when there is proper 

Alternatively, you can use getDependencyPath in jelly to pass the 
location of the collections JAR to your tag, then construct your own 
classloader to load the ListOrderedSet from.

- Brett

Steven Caswell wrote:

> Greetings.
> Perhaps there is some document that tells me how to fix this problem, 
> and I haven't stumbled across it yet.
> Here is the situation:
> I'm the author of an enhancement (that was incorporated in the latest 
> release) to the javadoc plugin that produces a report on the javadoc 
> warning in the same format as the checkstyle report. This enhancement 
> uses a java class to read the text version of the javadoc output (in 
> report.txt) and turns it into an xml file, which is then transformed 
> into the nicely formatted output.
> The plugin.jelly uses define:jellyBean to create a jelly bean for 
> invoking the java class, so the actual invocation is done as a tag 
> <javadoc:javadocwarnings ... />
> The java class depends on commons-collections 3.1 for a class 
> ListOrderedSet, which takes a no-arg constructor. This dependency is 
> declared in the plug-in's project.xml. The problem I'm having is that 
> the 3.0 version of ListOrderedSet does not have a no-arg constructor. 
> And it just so happens that the project I'm running javadoc against 
> has a dependency on ... you guessed it ... 3.0.  So the call to 
> <javadocwarnings> fails with an exception.
> I know I can fix the construction of ListOrderedSet to avoid the 
> problem, but I'm also interested in knowing how to force the 
> <javadocwarnings/> tag invocation to use the dependent jar as declared 
> in project.xml, rather than using my project's dependency.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message