On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz <[email protected]> wrote: > > On Monday 30 May 2016 15:28:04 Robert Munteanu wrote: > > On Fri, 2016-05-27 at 11:14 +0200, Oliver Lietz wrote: > > > I don't think there is support in Maven 3 for unit tests using a > > > different > > > version than for compile. Not sure if other build tools can handle > > > different > > > versions of dependencies for compile and test. > > > > Maven 3 is unable to do that. I can't say anything for other build > > systems. > > Looks like Gradle can do (but I haven't tested): > https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management
Yes, Gradle can do this. 'compile' and 'testRuntime' configurations are the standard configuration names that are relevant here and there is a natural inheritance chain (such that the default is that 'testRuntime' eventually inherits everything in 'compile'), but the versions used by 'testCompile/'testRuntime' can be overridden to be different (usually newer) ones than what is used by 'compile'/'runtime' I've done this plenty in the past when working with AEM to use newer APIs/frameworks in the tests than what the code is compiled against. such as compiling for AEM 5.6, but due to using newer versions of the Sling mock frameworks in test cases, having newer Sling jars pulled in as a result for test case compilation + execution. Maven can't do this, so it makes writing tests for the same code more difficult when using Maven when compared to Gradle under these circumstances. However, I don't particularly see this being enough reason alone to warrant the effort of having Sling switching to Gradle. There are some other possible benefits to using Gradle, such as being able to merge separate IT modules back into modules they are testing, therefore reducing the number of modules/build complexity. But even so, I still don't see Sling leaving Maven.
