Classpath order generated by eclipse plugin causes problems


(Stefan Sieber) #1

The Classpath ordering that is generated by the eclipse plugin causes problems with transitive dependencies. Consider the following case: -Project A has a dependency to Jar X version 1 -Project B has a dependency to project A and Jar X version 2

The .classpath file of project B generated by the eclipse plugin will list project A(and thus Jar X Version 1) before Jar X Version 2. This is wrong because during the gradle build Jar X version 2 is used.

It would be better if the project dependencies appeared after the dependencies to artifacts. I know this issue was discussed on the dev Mailing List, but I didn’t see any JIRA issue nor a topic here directly related to it. Discussion on Nabble: http://gradle.1045684.n5.nabble.com/Classpath-order-in-Eclipse-plugin-td4515748.html#a4528629

Issues that might be Related: - GRADLE-2016 - GRADLE-1835 - GRADLE-1614

I used the following workaround (inspired by GRADLE-1614)

eclipse.classpath.file{
        whenMerged{ classpath ->
            def projectRefs = classpath.entries.findAll{entry -> entry.kind =='src' && entry.path.startsWith('/')}
            //move the project references to the end of the list:
            classpath.entries.removeAll(projectRefs)
            classpath.entries.addAll(projectRefs)
           }
       }

I hope this might help somebody in the future :wink:


(Peter Niederwieser) #2

I don’t see how changing the order would help. Assume A depends on X:2 and B depends on A and X:1. Then the current order would lead to the correct result, and the changed order would not.

A potential solution is to not export any dependencies from Eclipse project A but add them explicitly to B. Then Gradle’s conflict resolution should kick in.


(Stefan Sieber) #3

I assumed that the Jars referenced by A already went through the Gradle conflict resolution. To be honest I didn’t verify my assumption.

Your proposal is certainly more robust and will produce the expected behaviour.