[
https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-4934:
-----------------------------------
Attachment: SLING-4934-v01.patch
Attached is a patch which includes all transitive dependencies from Sling
except for the dependencies of the mock bundles itself. Also it was necessary
to increase the version of o.a.s.testing.mock.sling.servlet and
o.a.s.testing.mock.sling.service because the interface {{SlingAdaptable}} is
now part of this Jar and being implemented by {{MockSlingHttpServletResponse}}.
That change required a change in the exported version according to the
baselining of bnd. The same for {{MockMimeTypeService}} which now implements an
interface which is part of the resulting Jar.
In general all interfaces which are implemented previously in an external
dependency and which now have been internalized require a version update.
> Sling Mock: Embed transitive dependencies
> -----------------------------------------
>
> Key: SLING-4934
> URL: https://issues.apache.org/jira/browse/SLING-4934
> Project: Sling
> Issue Type: Bug
> Components: Testing
> Affects Versions: Testing Sling Mock 1.4.0
> Reporter: Konrad Windszus
> Attachments: SLING-4934-v01.patch
>
>
> If you are using a DependencyManagement section in your pom refererencing a
> newer version of a dependency being also used by sling-mock, it will also
> influence the version of that transitive dependency of sling-mock at runtime.
> That may lead to issues like SLING-4392. Therefore I would suggest to also
> embed jcr.resource along with all other transitive dependencies within
> sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit.
> A related discussion can be found at
> http://www.mail-archive.com/dev%40sling.apache.org/msg47007.html, but that
> was not mentioning the problem with dependency management.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)