> On 07 Jun 2016, at 10:32, Konrad Windszus <konra...@gmx.de> wrote: > > Hi, >> On 07 Jun 2016, at 10:12, Oliver Lietz <apa...@oliverlietz.de> wrote: >> >> 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). > I agree that this is rather vague. We definitely need an official way of > upgrading dependencies. But in the cases of upgrading commons-lang and > commons-io I don't see any convincing reason to upgrade to the newest > dependency for the modules validation or health check (we don't actually > leverage new API there yet). Only if we do, we can and should discuss again. > >> >>> 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. > Not all ITs are based on Pax Exam. So the ones leveraging a real Sling > instance and being located in the same bundle as the code itself (Transporter > rule) are not that easy to decouple. >> >>> 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 >>> <https://issues.apache.org/jira/browse/SLING-5603> >>> and https://issues.apache.org/jira/browse/SLING-5685 >>> <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). > Ok, I will do so for Healthcheck Core in > https://issues.apache.org/jira/browse/SLING-5685 > <https://issues.apache.org/jira/browse/SLING-5685>. Actually it is unclear why the dependency to Commons IO was introduced at all for HC Core. Please also check https://issues.apache.org/jira/browse/SLING-5685?focusedCommentId=15318210&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15318210. @Oli: Can you quickly comment on that? Thanks
>> >> Regards, >> O. >> >>> Konrad >>> >>>> On 03 Jun 2016, at 13:32, Oliver Lietz <apa...@oliverlietz.de> wrote: >>>> >>>> On Friday 03 June 2016 20:13:29 Steven Walters wrote: >>>>> On Fri, Jun 3, 2016 at 6:20 PM, Oliver Lietz <apa...@oliverlietz.de> >> 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.
