I’ve hit an issue porting a complex multi-module project from maven to gradle: gradle seems to construct its dependency tree in the opposite order to maven.
The parent project has a dependency on validating-junit-surefire-provider and the child project has dependencies on junit and easymock. Maven seems to build the tree using the child dependencies first and then then adds in the parent dependency, whereas gradle does it the other way round.
Maven tree:
[INFO] ± junit:junit:jar:4.12:test
[INFO] | - org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] ± org.easymock:easymock:jar:3.4:test
[INFO] | - org.objenesis:objenesis:jar:2.2:test
[INFO] - com.xxx.testutilities:validating-junit-surefire-provider:jar:0.9:test
[INFO] - org.apache.maven.surefire:surefire-providers:pom:2.14.1:test
[INFO] - org.apache.maven.surefire:surefire-api:jar:2.14.1:test
Gradle tree:
±-- com.xxx.testutilities:validating-junit-surefire-provider: -> 0.9
| ±-- org.apache.maven.surefire:surefire-providers:2.14.1
| | — org.apache.maven.surefire:surefire-api:2.14.1
| — junit:junit:4.9 -> 4.12
| — org.hamcrest:hamcrest-core:1.3
±-- junit:junit: -> 4.12 (*)
— org.easymock:easymock: -> 3.4
— org.objenesis:objenesis:2.2
Any suggestions on how I get gradle to build the tree in the same order as maven?
I know that is this simple case it shouldn’t make any difference but in the depths of the actual project it is making the porting task very hard as dependency exclusions are not behaving in the same manner and tests that pass in maven aren’t passing in gradle.
There aren’t enough automated tests to prove that the new gradle build hasn’t broken the application and there are thousands of dependencies spread across hundreds of modules