Eclipse classpath: jars and source attachments from ivy dependencies


(rainer.frey) #1

I’m in the process of building an Ivy repository for exclusive use by gradle, with my own ivy.xml definitions for the dependencies. A must-have feature will be generating eclipse classpath files with sources attached to all opensource dependency jar files.

Can anyone outline how the ivy modules must be defined so that source artifacts are mapped to the corresponding jar artifacts (and not recognized as independent artifacts)?

I guess the ivy artifact type should be source, but what else? Is a certain configuration expected? How must the names of the source and jar artifacts relate? Can there be a single source archive for several jar artifacts in a single ivy module?

Any explanation, pointer to documentation or even the right part of the gradle source is appreciated.

Thanks Rainer


(Peter Niederwieser) #2

From what I recall, the IDE plugins will automatically download and attach source Jars if they have the same URL as the main Jar with a -src or -sources classifier added.

Why are you building an Ivy repository with your own ivy.xmls, in particular for open-source dependencies? With a repository manager like Artifactory and POMs from Maven Central, you will spend far less time on setup and maintenance and still have full control over dependency metadata when you need it.


(rainer.frey) #3

From what I recall, the IDE plugins will automatically download and attach source Jars

if they have the same URL as the main Jar with a -src or -sources classifier added.

Ah they need to have the same base URL. My layout includes an URL path element for the artifact type. Is the gradle code handling this reasonably extensible/configurable or should I better change the repository layout?

Why are you building an Ivy repository with your own ivy.xmls, in particular for open-source dependencies?

With a repository manager like Artifactory and POMs from Maven Central …

A number of our dependencies are not available via maven at all, and of the few that I looked into, the quality of the published maven modules was rather questionable. Transitive dependencies are not always correctly declared as optional, or reference wrong/outdated versions, sometimes the projects don’t publish to Maven central themselves, and the maven modules are provided by third party (who abandon them), in one case there was a version in Maven central, but newer versions are published to other repositories …

All in all my impression was that searching and verifying all published maven dependencies was not considerably less effort than building the repository myself, and with Ivy I have more flexibility to create configurations with our set of optional dependencies.

I also didn’t write the Ivy modules completely from scratch, but forked ivy roundup as a starting point.


(rainer.frey) #4

From what I recall, the IDE plugins will automatically download and attach source Jars

if they have the same URL as the main Jar with a -src or -sources classifier added.

OK, found out how it currently works: the IDE plugins automatically fetch a source jar file with the base name of the dependency module (as opposed to the artifact), and a sources classifier (src is not supported).

This jar is mapped to a binary jar with the same name.

This means, source (and javadoc) attachments in the IDE class path generation only work if * there is only one artifact in the module * the artifact has the same base name as the module itself

So multi-artifact ivy modules don’t work at all in this regard.

Found this out by debugging gradle code during build, esp. the class ‘org.gradle.plugins.ide.internal.IdeDependenciesExtractor’, most relevant methods are ‘extractRepoFileDependencies’ and ‘addSourceArtifact’

Any chance this might be addressed in gradle?


(Szczepan Faber) #5

We will address it at some point (pull request is welcome). There’s a jira ticket for it: http://issues.gradle.org/browse/GRADLE-2320