Good to know. We have one use case for this: JMockit. It uses class masking for ease of integration with junit, which requires it be on the classpath ahead of junit. I know masking is controversial, for good reason, but there it is.
I've been looking into this issue of ordering because I discovered that the Project.pom() method produces a pom.xml with dependencies in a non-deterministic order, which can result in maven builds resolving different versions of transitive dependencies than a pom.xml with the dependencies declared in the same order as they are declared in the build.gradle file. Looks like I can use dependencyManagement to compensate for this, but it does make the pom a little less predictable. In our project, we started with maven, converted to gradle, then built gradle tasks that generate the old poms (to maintain the mavenized project structure for some folks on the team). That's when the problems arose. Created a ticket for it: http://issues.gradle.org/browse/GRADLE-1512 -- View this message in context: http://gradle.1045684.n5.nabble.com/classpath-ordering-tp1431814p4373140.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
