hello robert. to clarify for the others, this does not affect the "primary mocks" jcr-mock and sling-mock, but only if you want to use one of the (more experimental) mocks with real repository underneath, namely sling-mock-jackrabbit and sling-mock-oak. for most usecases the resourcresolver-mock or jcr-mock will suffice and has not this problem.
but if a real repository like oak or jackrabbit is required one hits the problem as described by robert. 1+2 are real no options, 3 is quite inconvenient and complicates code coverage checks a lot. yes, embedding the oak/jackrabbit dependencies in the sling-mock-jackrabbit/sling-mock-oak artifacts could be a good option. the only small drawback i see is the bloating of the JAR file. perhaps we should give it a try. stefan >-----Original Message----- >From: Robert Munteanu [mailto:[email protected]] >Sent: Wednesday, June 10, 2015 5:08 PM >To: Sling Dev >Subject: Sling JCR Mocks, testing dependencies and imported ranges > >Hi, > >I'm starting to be very much convinced that the Sling Mocks are the >simplest way to add fast, repository and OSGi-enabled tests. Since they >are executed out-of-container, they can live in the same module as the >code under test. > >One conflict that I found with this approach is that while the Sling >JCR mocks - namely JCR_JACKRABBIT and JCR_OAK - require recent versions >of jackrabbit ( api, commons ), while we typically aim to keep the >dependency versions as low as possible. One example is the recent >change I added to the jcr.contentloader module [1], bumping the >jackrabbit-api version from 2.2.0 to 2.10.1 (!). > >I have considered various approaches, but none of them looks good. > >1. Declaring two dependencies with different scopes - used to work with >Maven 3, no longer works with Maven 2. >2. Just live with the more strict import range - a bad idea to restrict >bundles from running on older versions just because the tests need new >versions. >3. Split the tests in a different module - defies the purpose of having >the tests live with the code under test >4. Manually set the import-package versions in the pom.xml file - >manual and error-prone > >Hm ... writing this email I just got the idea of the JCR mocks >packaging all dependencies using the maven-shade-plugin [2] so that the >actual dependencies used for testing are not the ones used at compile >time and implicitly not the ones used to calculate dependencies. > >This means that for instance org.apache.sling.testing.sling-mock-oak >will embed all of oak and the dependendent jackrabbit apis. > >Thoughts? Alternatives? > >Thanks, > >Robert > >[1]: http://svn.apache.org/viewvc?view=revision&revision=r1684450 >[2]: https://maven.apache.org/plugins/maven-shade-plugin/
