I have a local (file based) ivy repository containing additional source and javadoc artifacts.
Unfortunately the gradle tooling api imports all artifacts as jar file (=classes) regardless of the artifact type (i.e. source).
I traced it down to: DefaultIdeDependencyResolver:getIdeRepoFileDependencies() [121]
Set<ResolvedArtifact> artifacts = getExternalArtifacts(configuration);
List<IdeExtendedRepoFileDependency> externalDependencies = new ArrayList<IdeExtendedRepoFileDependency>();
for (ResolvedArtifact artifact : artifacts) {
if (mappedResolvedDependencies.contains(artifact.getModuleVersion().getId())) {
IdeExtendedRepoFileDependency ideRepoFileDependency = new IdeExtendedRepoFileDependency(configuration, artifact.getFile());
ideRepoFileDependency.setId(artifact.getModuleVersion().getId());
externalDependencies.add(ideRepoFileDependency);
}
}
While the list of ResolvedArtifact still provides valid getType() infos, those never gets transfered into IdeExtendedRepoFileDependency, even if it has some extra fields for sourceFile and javadocFile.
The problem gets even more complicated, since different entries of externalDependencies have to be mapped into a single IdeExtendedRepoFileDependency …
Can you make a self-contained example of this problem? It sounds like something what we can fix. Is it just about filtering out source and jar artifacts?
The page about contributing is valid and describes currnet process.
Looking at your patch my first comment is that we would really like to see an integration test. There are several Idea*IntegrationTest Groovy classes where you can get an idea how to add it.
OK, I found IdeaSourcesAndJavadocJarsIntegrationTest. It runs fine with the internal ivy test repository. My problem seems to be a wrong or unusual ivy repository structure. I used an other layout pattern, but the main problem seems to be related to the ivy s. The integration tests differ jar/source/javadoc artifacts by separate configurations which are addressed explicitly. My own repository uses ‘default’ for all and thus the javadoc and source jars end up as separate bogus java libs.
I still have some problems to set up a proper debug environment (using IDEA) to get a deeper understanding of my problem. Building gradle-2.0-rc-1 with gradlew works fine, but my IDEA complains about groovy errors (just started with groovy…).
Is it OK to compile gradle using java7 (or even java8?).
After I was able to build gradle and analyzed the integration tests I realized that my problem was not related to ide integration in general nor Intellij in particular. Instead it simply depends on my ivy repository constitution since it does not discriminate different artifact types by different configurations.
Most of the ‘AbstractSourcesAndJavadocJarsIntegrationTest’ work well, since ‘addCompleteConfigurations()’ applies individual conf attributes. However the ‘“sources and javadoc jars stored with maven scheme in ivy repositories are resolved and attached”’ reproduces my problem nicely: the generated root.iml file contains two additional bogus libraries. Unfortunately this is not recognized.
I simply added some assertion to demonstrate the problem.
Thanks for your detailed analysis. I was able to replicate the issue you’re seeing by adding the extra assertion to ‘IdeaSourcesAndJavadocJarsIntegrationTest’. However, on further inspection the failure was caused by a bug in our test code: the line in the test
was actually adding the artifact to the generated ivy.xml file, unintentionally.
The intended behaviour is to handle sources and javadoc artifacts that are not declared in ivy.xml, but simply stored using the maven scheme of ‘{name}-sources.jar’ and ‘{name}-javadoc.jar’.
So for ivy files you have a few options: - Use whatever classifier scheme you like, and declare the artifacts in ivy.xml using the ‘sources’ and ‘javadoc’ configurations - Use the maven classifier scheme, and don’t declare the artifacts in ivy.xml
Yep, I did not realize that undeclaredArtifact() adds artifacts without any type attribute (which is “jar” by default). It was probably a bad idea anyway to hitchhike some other test. Next try is a separate test I added to AbstractSourcesAndJavadocJarsIntegrationTest:
After it pointed out that my trouble was caused by an ill organized Ivy repository this thread seems dead now, since it did not show up any relevant bugs of Gadle or the tooling api.
If I still think to see a problem treating Ivy Artifact.getType() attributes right, does it help to open a new topic with a better subject to discuss it? May be it will be relevant for the upcoming Ivy publishing support, too.