hello konrad. i'm not sure if embedding more dependencies into the sling-mock JAR is a good idea.
one main idea when designing sling-mock was that it should not be tied to a certain (esp. not only the newest) sling version/dependencies to still allow using it in projects that are using a sling version that is a bit older. in fact up to now sling-mocks imports only dependencies from ~mid 2013 and is thus quite compatible with most sling versions from then up to now for the most common testing use cases. when new features are added to APIs that need implementations we implement them in the mocks as well, but to not raise the dependency version to not force all users to this update. each project that uses sling-mocks usually has some dependencies already declared (e.g. the sling api version it uses), so this overwrites the dependencies from sling-mock. this approach has limitations: when a new interface we want to be upwards compatible to but not update the dependency version references a class not available in the old dependencies this way is no longer possible. fortunately this happens quite rarely. SLING-4932 may be such a case. aem-mock [1] for example overwrites all related dependencies with those from AEM6 because this is the main version the wcm.io libraries are currently targeted at. but with a different set of dependencies it should be possible to use sling mock with newer or older sling versions as well. of course it can be a bit brittle to get the dependencies right which may be inconvenient for the user. but when we embed some dependencies with a fixed version this may breaks this wide-range version compatibility, or at least may introduce a different behavior e.g. for the JCR-sling-resource mapping than is used really in the project itself, lessening the trustability of the unit tests. for oak or jackrabbit embedding the dependencies is not problematic, because sling and oak/jackrabbit are only "loosely coupled" via their respective APIs which are quite stable. obviously i want to avoid to have to maintain an own sling-mock version for each sling version or combination of sling api/jcr resource mapping/etc. version. stefan [1] http://wcm.io/testing/aem-mock/ >-----Original Message----- >From: Konrad Windszus [mailto:konra...@gmx.de] >Sent: Friday, August 07, 2015 3:04 PM >To: dev@sling.apache.org >Subject: Re: Sling JCR Mocks, testing dependencies and imported ranges > >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/
