You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Konrad Windszus (JIRA)" <ji...@apache.org> on 2015/08/07 14:55:46 UTC
[jira] [Updated] (SLING-4934) Sling Mock: Embed transitive
dependencies
[ https://issues.apache.org/jira/browse/SLING-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Konrad Windszus updated SLING-4934:
-----------------------------------
Description: 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 within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit. (was: 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. That may lead to issues like SLING-4392. Therefore I would suggest to also embed jcr.resource within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit.)
> 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
>
> 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 within sling-mock, similar to what was done in SLING-4827 for sling-mock-jackrabbit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)