[ 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)