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/
