Hi Stefan, > On 12 Aug 2015, at 21:26, Stefan Seifert <[email protected]> wrote: > > 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. "Is thus quite compatible" sounds too fuzzy for me. Since it is way too much effort to list which dependency versions are supported I would rather support only one version (which is the newest) and make that version unchangeable through e.g. dependencyManagement by embedding it.
> > 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. Updating sling-mock to a newer version which e.g. depends on a brand new version of sling API does not mean your code does need to depend on the same version of Sling API. You can easily override that by explicitly stating another dependency in your pom. That also won’t interfere with the maven-bundle-plugin as that will only evaluate the Maven compile class path (which sling-mock should never be part of) to figure out the import version range for packages. > > 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. Since most of the API is backwards compatible anyways I don’t really see the risk here, if you use a different implementation in your unit test leveraging sling-mock as in your production environment. In the end you don’t want to test if the Sling/Jackrabbit/Oak implementation is correct rather than if your own code is correct. Could you give a good example where using sling-mock with a newer version of some Sling/Jackrabbit/Oak dependency lead to compatibility problems (i.e. your code runs in sling-mock, but not in your production environment)? What exactly has been changed in the jcr-resource mapping that would require testing with an older Sling dependency? > > 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. I completely understand and therefore would only support the newest version (because testing should still cover old API usages, because it should be backwards compatible in most of the cases). Thanks, Konrad > > stefan > > [1] http://wcm.io/testing/aem-mock/ > > >> -----Original Message----- >> From: Konrad Windszus [mailto:[email protected]] >> Sent: Friday, August 07, 2015 3:04 PM >> To: [email protected] >> 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 <[email protected]> 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:[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/ >
