RE: Sling JCR Mocks, testing dependencies and imported ranges
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
Re: Sling JCR Mocks, testing dependencies and imported ranges
Hi Stefan, On 12 Aug 2015, at 21:26, Stefan Seifert sseif...@pro-vision.de 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: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
RE: Sling JCR Mocks, testing dependencies and imported ranges
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). projects should contain the set to all sling bundle dependencies in their parent POMs which are used in their sling lauchpad or AEM version. then it is ensured sling-mock and the unit tests uses exactly that versions. and we try our best that sling-mock can use both old and new dependencies (e.g. via some reflection magic as in SLING-4932). embedding the dependences removes this control from the users which may lead to problems. e.g. embedding jcr.resource 2.5.4 would force uses to declare sling API 2.9.0 dependencies in their POM as well, otherwise the unit tests will fail. and in maven 3 it's no longer possible to define different versions for compile scope and test scope. stefan
Re: Sling JCR Mocks, testing dependencies and imported ranges
On Mon, 2015-08-10 at 12:56 +0200, Konrad Windszus wrote: Hi Robert, thanks for your comments on that. On 10 Aug 2015, at 12:21, Robert Munteanu romb...@apache.org wrote: On Fri, 2015-08-07 at 15:04 +0200, Konrad Windszus wrote: 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? I don't think there's a problem with embedding the dependencies here. Two questions related to your patch: 1. Is there a way to ensure that we embed the same versions? I think that if we use sling-mock and sling-mock-oak for instance, and they embed different versions we will get classpath clashes. Maybe we could set up some IT projects where this gets verified… Yeah, very true. Especially if we would pass classes around being embedded by both JARs like ResourceResolverFactory or SlingRepository from ResourceResolverTypeAdapter. Unfortunately I don’t have a very good idea on how to check that with an IT. Probably at least the Sling API should never be embedded, as that will for sure clash. Do you have any idea, on how we could test that sufficiently? Not really. It _might_ be enough to run the tests in the sling-mock -jackrabbit and sling-mock-oak tests, as those would pull in the sling -mock module. 2. Why did you set createDependencyReducedPom = false? IIUC this means that some depending on sling-mock will pull in transitive dependencies in the classpath anyway. Yes, that is true. But when I enable that the dependency-reduced -pom.xml is generated without the Apache License Header and therefore the apache-rat-plugin does complain. I could disable the check of the apache-rat-plugin but that would mean, we would deploy a pom.xml without a Apache License Header to Maven Central (and I am not sure this is allowed). Also I didn’t have any problems with the transitive dependencies. How did you solve that for sling-mock-oak? I guess I did not :-) But indeed this could be problematic when distributing the pom file ( both on Maven central and on dist.apache.org ). I noticed that I don't need a dependency-reduced-pom for Jackrabbit, since the embedded dependencies actually come from the org.apache.sling.commons.testing module. That's one possibility that we can consider. Alternatively we can look into altering the dependency -reduced-pom.xml to have a license header. Robert Thanks, Robert 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
Re: Sling JCR Mocks, testing dependencies and imported ranges
Hi Robert, thanks for your comments on that. On 10 Aug 2015, at 12:21, Robert Munteanu romb...@apache.org wrote: On Fri, 2015-08-07 at 15:04 +0200, Konrad Windszus wrote: 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? I don't think there's a problem with embedding the dependencies here. Two questions related to your patch: 1. Is there a way to ensure that we embed the same versions? I think that if we use sling-mock and sling-mock-oak for instance, and they embed different versions we will get classpath clashes. Maybe we could set up some IT projects where this gets verified… Yeah, very true. Especially if we would pass classes around being embedded by both JARs like ResourceResolverFactory or SlingRepository from ResourceResolverTypeAdapter. Unfortunately I don’t have a very good idea on how to check that with an IT. Probably at least the Sling API should never be embedded, as that will for sure clash. Do you have any idea, on how we could test that sufficiently? 2. Why did you set createDependencyReducedPom = false? IIUC this means that some depending on sling-mock will pull in transitive dependencies in the classpath anyway. Yes, that is true. But when I enable that the dependency-reduced-pom.xml is generated without the Apache License Header and therefore the apache-rat-plugin does complain. I could disable the check of the apache-rat-plugin but that would mean, we would deploy a pom.xml without a Apache License Header to Maven Central (and I am not sure this is allowed). Also I didn’t have any problems with the transitive dependencies. How did you solve that for sling-mock-oak? Thanks, Robert 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.
Re: Sling JCR Mocks, testing dependencies and imported ranges
On Fri, 2015-08-07 at 15:04 +0200, Konrad Windszus wrote: 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? I don't think there's a problem with embedding the dependencies here. Two questions related to your patch: 1. Is there a way to ensure that we embed the same versions? I think that if we use sling-mock and sling-mock-oak for instance, and they embed different versions we will get classpath clashes. Maybe we could set up some IT projects where this gets verified... 2. Why did you set createDependencyReducedPom = false? IIUC this means that some depending on sling-mock will pull in transitive dependencies in the classpath anyway. Thanks, Robert 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=revisionrevision=r1684450 [2]: https://maven.apache.org/plugins/maven-shade-plugin/
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=revisionrevision=r1684450 [2]: https://maven.apache.org/plugins/maven-shade-plugin/
Re: Sling JCR Mocks, testing dependencies and imported ranges
On Fri, 2015-06-12 at 09:20 +0200, Bertrand Delacretaz wrote: On Thu, Jun 11, 2015 at 4:43 PM, Stefan Seifert sseif...@pro-vision.de wrote: ...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... I don't think that's really a problem considering that those jars are meant to be used for testing only. +1 for embedding. I've done this for the sling-oak-mock project in SLING-4824 [1] and this seems to work fine for the jcr.contentloader bundles [2]. I'll give this some time to settle and if everything works out fine I'll do the same for sling-mock-jackrabbit. Robert [1]: https://issues.apache.org/jira/browse/SLING-4824 [2]: https://svn.apache.org/r1686423
RE: Sling JCR Mocks, testing dependencies and imported ranges
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=revisionrevision=r1684450 [2]: https://maven.apache.org/plugins/maven-shade-plugin/
