I would like to wrap things up here: So it seems the common agreement is:
1) Depend on the lowest possible version of a dependency (to let bnd generate import package ranges which are as broad as possible to support as many different systems as possible (even old ones)). A module should only be upgraded to a newer dependency in case this is really necessary (because of a feature being used which is not available in earlier version or if the newer version contains a bugfix from which the consumer bundle is affected). 2) For ITs and the Maven Launchpad depend on the same version which is reasonably new (this is only possible if the IT is in a dedicated Maven bundle). 3) Since Maven does not completely separate compile and test classpath for the unit test we must depend on the lowest possible version as well. If everyone is fine with that, I would ask Oliver Lietz to basically revert some changes being done in https://issues.apache.org/jira/browse/SLING-5603 and https://issues.apache.org/jira/browse/SLING-5685. Thanks for your input, Konrad > On 03 Jun 2016, at 13:32, Oliver Lietz <[email protected]> wrote: > > On Friday 03 June 2016 20:13:29 Steven Walters wrote: >> 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. > > Same here. That would be a lot of work and I don't think the project can > perform such a big task right now. > > O. >
