[
https://issues.apache.org/jira/browse/SLING-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676827#comment-16676827
]
Konrad Windszus commented on SLING-8060:
----------------------------------------
bq. sling-mock should not force the using project which alternative is used -
or which osgi version is used. esp. it may lead to subtle problems if it
introduces another version of a dependency already referenced in the using
project by an alternative way to address the dependency.
Sling Mocks should IMHO reference one(!) default version of OSGi with which it
is supposed to work and against which it was tested. This does not only affect
compendium classes but also core classes and even dependencies outside of OSGi!
IMHO even projects not defining any dependencies should be able to use
sling-mocks with just that single test dependency. If someone wants to
overwrite the version of compendium/core classes used internally during testing
he can still do that by leveraging dependencyManagement. I think it should just
be documented which GAV needs to be managed in this case.
What is the exact use case you have in mind, why you would want to overwrite
the OSGi compendium class version?
> Sling Testing Mocks: Transitive dependencies necessary at test execution time
> should be defined with scope "compile"
> --------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-8060
> URL: https://issues.apache.org/jira/browse/SLING-8060
> Project: Sling
> Issue Type: Bug
> Components: Testing
> Affects Versions: Testing OSGi Mock 2.4.2, Testing Sling Mock 2.3.4
> Reporter: Konrad Windszus
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently Testing OSGi Mock and Testing Sling Mock have a class execution
> time dependency to e.g. OSGi Configuration Admin and Event Admin (in
> https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/b04e06522379d32552353304746fbcdb09258460/core/src/main/java/org/apache/sling/testing/mock/osgi/MockOsgi.java#L312
> and in
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/ef994bfbc9ae2288c66ef8be7fd3997913cc9144/core/src/main/java/org/apache/sling/testing/mock/sling/ResourceResolverFactoryInitializer.java#L42).
> Still the dependency to it is only defined with scope "provided" in
> https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/blob/b04e06522379d32552353304746fbcdb09258460/parent/pom.xml#L49
> and
> https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/986bdfbbf6c3f5f416d6acc24329eb431f67494a/core/pom.xml#L37.
> That is a problem as transitive dependencies with scope "provided" are not
> included in the classpath. That may lead to the fact that the
> ConfigurationAdmin/EventAdmin is not part of the testing classpath (in case
> it isn't explicitly defined for some other reason) . Please make sure that
> all dependencies which are actually always necessary at test execution time
> are included with scope "compile"
> (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope).
> This issue does not happen that often, as in most of the cases the to be
> tested modules already define an explicit dependency to
> {{org.osgi:osgi.cmpn}} and {{org.osgi:osgi.core}}, but since nowadays the
> OSGi foundation provides not only the aggregate dependencies but also
> individual ones, this is no longer necessarily the case (compare with
> https://issues.apache.org/jira/browse/SLING-7384?focusedCommentId=16327433&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16327433).
> At the same time of converting the dependency scope to "compile" we should
> switch from the aggregate to the individual osgi artifacts (to be able to
> more granularly define which OSGi level is used).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
