Thanks for clarifying, good to know that this behavior is intended, and I’ll try to design my repository according to it for the time being.
As for that being “the right thing”, I’m a bit confused why this is desirable. Maybe I’m missing something, as I never used maven, and don’t have any prior practical experience with ivy as well.
Peter said: > If you add a source Jar as a dependency in a POM (which is not normally done), it will end up on the corresponding class path.
I wonder when I would ever want to have a source jar in the compile classpath, or any other dependency artifact that is not a binary jar.
In ivy I don’t declare dependencies on an artifact, but on a module, in a certain configuration (usually).
So I would expect “the right thing” to be: add all artifacts of the matching module and configuration to the compile classpath, that are meant to be used as compile classpath.
And use other types of artifacts, also limited to the declared configuration(s), for other, suitable, purposes within the build, e.g. as IDE source references.
I’m using a private ivy repository only, no maven repository, and I’m still not sure what I should do regarding source jars. If I put the source jar artifacts into the same configuration as the actual binary jars, the sources are put on the compile classpath. If I put them in a separate configuration on which I must not depend in my gradle dependency declaration, they are never even fetched at all.
The IDE plugins’ dependency extractor uses a mechanism to try and fetch a single source artifact with the name of the complete ivy module and a classifier of “sources” (which, as Peter or Luke mentioned has usually no meaning in Ivy), and does not check at all what artifacts are declared for the module. This does not work at all for Ivy modules with multiple artifacts in different configurations (as I have several in my repository).
To work around this, I was hoping to be able to look into the full list of the artifacts of my gradle dependency configurations, and map (e.g. by repository-specific convention), source type artifacts to binary artifacts myself. Obviously this doesn’t work, because either the sources are in a module configuration that I depend on, and thus on the classpath, or they are not, and thus not referenced by the gradle dependency configurations at all.
I’d appreciate two things: 1. any advise how I could, with current gradle, achieve a clean classpath without sources, and still somehow get a hold on source artifacts for setting up IDEs with Ivy 2. maybe it could be considered for future versions of gradle to distinguish between artifact types or kinds, and only use a suitable artifact subset of the dependencies for the Java classpath, but still provide the other artifacts for other build purposes.