On Monday 06 June 2016 14:57:16 Konrad Windszus wrote: > I would like to wrap things up here: > > So it seems the common agreement is:
Really? > 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). I don't see all topics discussed and your definition is very vague. It can be taken as "never upgrade". This prevents modernization of our code base (example given). > 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). Pax Exam can pull in any version of a dependency even when running in the same module. The limitation to one version is only true for our current setup of unit tests with Maven 3. > 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, To make clear you are the driving force behind this approach please go ahead and revert yourself (and don't forget to adjust fixed versions). Regards, O. > 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_plug > >>> in > >>> _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.
