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 > > So my preferred answers to eliminate outdated dependencies in tests: > > > > 1. use minimal version for compile and current version for test > > (how?) > > 2. use current version for compile and test > > 3. use current version for compile and test and carefully expand > > import range > > We seem to be discussing 'test' but I think we need to separate unit > tests stored in the same Maven projects and integration tests. "I don't think there is support in Maven 3 for *unit* tests using a different version than for compile." - it's about unit tests, sorry if it wasn't clear enough. > a) Integration tests should use the same dependencies as the launchpad. > After all, the launchpad is what we ship and things should work fine in > that setup. If other parties want different combinations, they're free > to define those combinations and test it themselves. We have different setups for ITs so that is not always given (pure Pax Exam, based on Sling Start, external Launchpad, Pax Exam Karaf, ...). And yes, current Launchpad should be the benchmark for new releases. Other parties are free to backport new releases for older systems. > b) Unit tests may aim to use the same dependencies as the launchpad. I > am not thoroughly convinced of the value, given that unit tests only > touch the surface of an API. Chances of not finding out issues due to a > missed upgrade of commons-lang are way smaller that missing an upgrade > to oak-core ( for instance ). AFAIR we are moving ITs closer to the code under test (Bertrand?) and we already have some heavy unit tests for some modules which do not have equivalent ITs, e.g. Event, Discovery, Distribution, Engine. Please do not underrate our unit tests. Commons Collections changed behavior from 3.2.1 to 3.2.2 due to unsafe serialization. Similar changes can happen in other libraries for what ever reason. How will we notice we are affected? Reports from users? > Also, it's quite troublesome to keep all versions of all modules in > sync with the launchpad. All that manual work is bound to get mistakes > for - again, IMO - little gain. > > So I would say that if we want to align unit test dependencies with the > launchpad versions we should have: > > 1. An automatic way of defining dependency versions > 2. A way of separating unit test from compile dependencies I don't think we need to keep all modules in sync. But we should do a moderate modernization of (3rd party) libraries, instead of keeping backwards compatibility forever for the sake of itself. This leads to ugly code and we may miss incompatibilities with Launchpad. Again, other parties are free to backport new releases for older systems or upgrade libraries also (AEM 6.1 works well with Commons Lang 3.4). Regards, O. > Thanks, > > Robert
