You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Robert Munteanu <ro...@apache.org> on 2015/06/10 17:07:58 UTC
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/
Re: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Robert Munteanu <ro...@apache.org>.
On Fri, 2015-06-12 at 09:20 +0200, Bertrand Delacretaz wrote:
> On Thu, Jun 11, 2015 at 4:43 PM, Stefan Seifert <
> sseifert@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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jun 11, 2015 at 4:43 PM, Stefan Seifert <ss...@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.
-Bertrand
RE: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Stefan Seifert <ss...@pro-vision.de>.
>> 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
Posted by Konrad Windszus <ko...@gmx.de>.
Hi Stefan,
> On 12 Aug 2015, at 21:26, Stefan Seifert <ss...@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:konrad_w@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 <ss...@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:rombert@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/
>
RE: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Stefan Seifert <ss...@pro-vision.de>.
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:konrad_w@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 <ss...@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:rombert@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/
Re: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Robert Munteanu <ro...@apache.org>.
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 <ro...@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 <
> > > > sseifert@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:rombert@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/
> > >
> >
>
Re: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Konrad Windszus <ko...@gmx.de>.
Hi Robert,
thanks for your comments on that.
> On 10 Aug 2015, at 12:21, Robert Munteanu <ro...@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 <ss...@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:rombert@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/
>>
>
Re: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Robert Munteanu <ro...@apache.org>.
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 <ss...@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:rombert@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/
>
Re: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Konrad Windszus <ko...@gmx.de>.
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 <ss...@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:rombert@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/
RE: Sling JCR Mocks, testing dependencies and imported ranges
Posted by Stefan Seifert <ss...@pro-vision.de>.
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:rombert@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/