[
https://issues.apache.org/jira/browse/SLING-11870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-11870:
-----------------------------------
Description:
jcr-mock users some helper classes from jackrabbit and oak for implementing the
mocks.
for this, some individual oak dependencies are declared in the POM, e.g.
{{oak-jackrabbit-api}} and recently added {{oak-security-spi}}, in
https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/20 was
also discussion about {{oak-commons}}.
although usually it is best practice to reference exactly the artifact that
contains the required classes, it makes managing the oak version in downstream
projects more difficult, when the downstream projects want to test against a
newer version of oak. that downstream projects usually do not define every
single oak-dependency, but only {{oak-jcr}} which pulls in all other deps.
example:
https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/blob/e1692937ea4094ad5689429bdfae2dc0e85cf70d/pom.xml#L85-L105
to simplify the oak version management in unit test contexts, jcr-mock should
also directly reference {{oak-jcr}} and can use any classes in it's
dependencies.
was:
jcr-mock users some helper classes from jackrabbit and oak for implementing the
mocks.
for this, some individual oak dependencies are declared in the POM, e.g.
{{oak-jackrabbit-api}} and recently added {{oak-security-spi\\, in
https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/20 was
also discussion about {{oak-commons}}.
although usually it is best practice to reference exactly the artifact that
contains the required classes, it makes managing the oak version in downstream
projects more difficult, when the downstream projects want to test against a
newer version of oak. that downstream projects usually do not define every
single oak-dependency, but only {{oak-jcr}} which pulls in all other deps.
example:
https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/blob/e1692937ea4094ad5689429bdfae2dc0e85cf70d/pom.xml#L85-L105
to simplify the oak version management in unit test contexts, jcr-mock should
also directly reference {{oak-jcr}} and can use any classes in it's
dependencies.
> jcr-mock: Use org.apache.jackrabbit:oak-jcr as only oak dependency
> ------------------------------------------------------------------
>
> Key: SLING-11870
> URL: https://issues.apache.org/jira/browse/SLING-11870
> Project: Sling
> Issue Type: Improvement
> Components: Testing
> Affects Versions: Testing JCR Mock 1.6.8
> Reporter: Stefan Seifert
> Assignee: Stefan Seifert
> Priority: Major
> Fix For: Testing JCR Mock 1.6.10
>
>
> jcr-mock users some helper classes from jackrabbit and oak for implementing
> the mocks.
> for this, some individual oak dependencies are declared in the POM, e.g.
> {{oak-jackrabbit-api}} and recently added {{oak-security-spi}}, in
> https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/pull/20 was
> also discussion about {{oak-commons}}.
> although usually it is best practice to reference exactly the artifact that
> contains the required classes, it makes managing the oak version in
> downstream projects more difficult, when the downstream projects want to test
> against a newer version of oak. that downstream projects usually do not
> define every single oak-dependency, but only {{oak-jcr}} which pulls in all
> other deps. example:
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/blob/e1692937ea4094ad5689429bdfae2dc0e85cf70d/pom.xml#L85-L105
> to simplify the oak version management in unit test contexts, jcr-mock should
> also directly reference {{oak-jcr}} and can use any classes in it's
> dependencies.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
