Actually this does also affect sling-mocks IMHO (please compare with https://issues.apache.org/jira/browse/SLING-4932 <https://issues.apache.org/jira/browse/SLING-4932>). Therefore I suggest to also do the embedding in sling-mocks (https://issues.apache.org/jira/browse/SLING-4934 <https://issues.apache.org/jira/browse/SLING-4934>). Usually in our projects we have one big dependency management section reflecting the actual versions being running in Apache Felix (i.e. the runtime version). This may be newer versions than the ones sling-mocks is using. Unfortunately the dependency management does also affect the transitive dependencies of sling-mock at run-time (i.e. while executing the tests). Anything speaks against embedding all transitive dependencies there? Konrad
> On 11 Jun 2015, at 16:43, Stefan Seifert <sseif...@pro-vision.de> wrote: > > 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:romb...@apache.org] >> 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/
