JetGradle + Ivy: useless dependencies on source arifacts

I switched to Gradle and build a local Ivy repository (from Ivy RoundUp).
Using JetGradle it generates a dependency tree. Unfortunately it contains all javadoc and source atrifacts, too:-)

I.E. my Ivy.xml contains:

<info organisation="org.apache.xerces" module="xerces" revision="2.10.0" ...>
        <artifact ivyde:source="source" name="xercesImpl" conf="impl"/>
        <artifact ivyde:source="source" name="serializer" conf="serializer"/>
        <artifact name="source" type="source" ext="zip"/>
        <artifact name="javadoc" type="javadoc" ext="zip"/>
        <artifact name="javadoc-other" type="javadoc" ext="zip"/>
        <artifact name="javadoc-xerces2" type="javadoc" ext="zip"/>
        <artifact name="javadoc-xni" type="javadoc" ext="zip"/>
        <artifact name="javadoc-xs" type="javadoc" ext="zip"/>

thus JetGradle generates dependencies like:


Even worse all of them are treated as <CLASS> libraries :-(
Instead of creating additional IDE-libraries <JAVADOC> and <SOURCE> entries should be created.

Is it a problem with JetGradle or is something wrong with my Gradle or Ivy definitions (I'm new to both ...)

I'm using 12.1.4 ultimate with gradle-1.3

Regards, Dieter.

Comment actions Permalink

Meanwhile I downloaded the IDEA sources to understand whats going on here.

I found that gradle/ivy returns jars or zips like "javadoc-xerces2" with a LibraryPathType.BINARY instead of SOURCE.
Unfortunately this assignment seems to happen within the gradle daemon as I just receive the serialized object via RMI.
Is it possible to debug into the gradle daemon, too? or to switch on some more verbose logging?
I'm relatively new to gradle and i just start to understand how it works.

The decision to choose LibraryPathType.BINARY however must have been implemented somewhere in the gradle plugin, since this enum is not part of the gradle code...
Most assignments I found are mappings form internal OrderRootType -> LibraryPathType.
Where happens the mapping of gradle -> LibraryPathType?


Comment actions Permalink

Hi Dieter,

I assume that the problem is that gradle tooling api returns incorrect information about project structure. IJ gradle integration uses code like below for that:

GradleConnector connector = GradleConnector.newConnector();
ProjectConnection connection = connector.connect();
ModelBuilder<IdeaProject> modelBuilder = connection.model(IdeaProject.class);

(exact details can be found at GradleProjectResolver and GradleExecutionHelper classes)

I.e. you can write a simple console application which does the same and check what is returned by gradle api for your project.

Also you can debug gradle sources (the stuff under gradle daemon hood). There is a convenient method which allows to do the job in-process - org.gradle.tooling.internal.consumer.DefaultGradleConnector.embedded(true).


Comment actions Permalink

Hi Denis,

thanks for help.

My debugging attempts ended at a similar point.
But while your code pointers are from the master branch I switched to 129 to be in sync with my current idea release 129.713.
Should I switch to the master branch, too?

Meanwhile I found an other aspect, don't know if it is related.
With gradle I get a list of all dependencies using:

    task listRuntimeJars << {
        configurations.runtime.each { File file -> println ">> " }

This also lists all files regardless if those are binary, sources or javadoc.
While org.gradle.api.artifacts.Configuration extends FileCollection and such provides a plain list of Files,
I'm interested in the metadata provided by Ivy and how to use the Configuration interface to extract them.
The interface provides additional methods I currently try to understand...

Thus I'm about to debug gradle and will give DefaultGradleConnector.embedded(true) a try.

With JetGradle I think I have to attach to the gradle server process somehow (found: RemoteGradleProcessSettings)...


Comment actions Permalink

Both 12.1.x and 13.x use the same approach fore querying gradle api about project info (I mentioned it above). Anyway, I believe the problem is at gradle side, so, you can use not IJ gradle integration but write a simple class which works with gradle api directly instead.

Regarding IJ gradle integration debugging facilities - you can uncomment line ' //params.getVMParametersList().addParametersString("-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5009");' at GradleApiFacadeManager (IJ 12.1.x) or ExternalSystemFacadeManager (IJ v.13.x). That makes slave process which IJ uses for communication with gradle api waiting for incoming remote debugger connection.


Comment actions Permalink

I think you are right. Our kind of working with Ivy may be quite unusual (compared to the main maven user).
Thus JetGradle seems to be unable to synchronize my IDEA project out of the box.
(have to learn more about how the gradle tooling API works and how to use it ...).

May be it's possible to derive proper IDEA library entries from the Ivy descriptions using gradle itself.
I found some gradle plugin to generate IDEA project settings, but it seems to stuck to the legacy .ipr format.

Unfortunately I did not found how to prevent JetGradle from updating my IDEA project automatically (and thus breaking it).
I switched off "auto-import" from the gradle setup page, but sometimes JetGradle updates my project libraries regardless :-(
Thus I have to switch off JetGradle completely, even if other functionalities may still be quite useful.


Comment actions Permalink

No automatic project structure update must be performed if auto-import is off. You can file a bug at our tracker if there are stable steps to reproduce the problem.


Comment actions Permalink

Hi Denis,

I just hit the event while debugging IDEA itself:

While JetGradle loads the Gradle project, one of my project libraries gets replaced by a misidentified zip file containing javadoc.
The misidentification is a Gradle problem discussed above, but modifying my project library at this time is a bug, since  auto-import is definitely off.

I traced it down to GradleMovedJarsPostProcessor.processChanges():
I got 169 GradleProjectStructureChange request. Only one of those changes generates a single MergeInfo which gets merged into my project:

Until now I used current 12.1.4 (129). I just switched to master and found that everything changed drastically.
I'll try to find if the problem still exist on the master brach...


Comment actions Permalink

Even with the current 135.690 (13.1.2) importing of libraries from my ivy repository fails since jar/source/doc artifacts are not discriminated.
I traced it down a bit further and posted the problem (as far as I understand it) to the gradle community:



Please sign in to leave a comment.