ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: IVYDE: shared javadoc attachments
Date Tue, 12 Jan 2010 14:30:40 GMT
On Mon, 11 Jan 2010 15:03:16 -0900, Jason Guild <>
> Hi All:
> Got a question about javadoc attachments in IvyDE ( / Ivy 
> (
> I am using the default URL resolver against the Ivy repo on our dev web 
> server.
> The artifact pattern we are using in our ivy settings is:
> <artifact 
> />
> I've got a module, let say, called 'foo' which publishes multiple JAR 
> artifacts:
> foo-a-1.0.0.jar
> foo-b-1.0.0.jar
> foo-c-1.0.0.jar
> If I specify my project depends on 'foo', IvyDE happily pulls down all 
> three components.
> The foo module is unfortunately /closed/ and the javadocs are provided 
> in one archive ''.
> So I put the archive on the server and I modify the ivy.xml for the foo 
> module to publish the docs via:
> <artifact name="foo" type="javadoc" ext="zip" conf="default" 
> e:classifier="doc"/>
> Now IvyDE/Ivy will happily pull down the javadoc along with all the 
> other artifacts.
> But, none of the foo-a, foo-b, or foo-c artifacts have javadoc 
> attachments (presumably because their artifact basenames do not match).
> Without fetching the same 6MB javadoc archive three times under three 
> different names, is it possible to get IvyDE to treat the one javadoc 
> artifact as a candidate for attachment on each of the component JAR 
> artifacts?

There is no way with the current implementation.
I discussed this issue with a colleague some time ago and we started to
think about adding extra metadata in the ivy.xml. For instance we were
thinking of adding some attributes on the artifacts like:
<artifact name="foo-a" type="jar" ext="jar" conf="default"
ivyde:javadoc="foo" />
<artifact name="foo-b" type="jar" ext="jar" conf="default"
ivyde:javadoc="foo" />
<artifact name="foo-c" type="jar" ext="jar" conf="default"
ivyde:javadoc="foo" />

If you have any other idea you are welcomed to open a new feature entry in
the Jira.


View raw message