>> obviously i want to avoid to have to maintain an own sling-mock version for >each sling version or combination of sling api/jcr resource mapping/etc. >version. >I completely understand and therefore would only support the newest version >(because testing should still cover old API usages, because it should be >backwards compatible in most of the cases).
projects should contain the set to all sling bundle dependencies in their parent POMs which are used in their sling lauchpad or AEM version. then it is ensured sling-mock and the unit tests uses exactly that versions. and we try our best that sling-mock can use both old and new dependencies (e.g. via some reflection magic as in SLING-4932). embedding the dependences removes this control from the users which may lead to problems. e.g. embedding jcr.resource 2.5.4 would force uses to declare sling API 2.9.0 dependencies in their POM as well, otherwise the unit tests will fail. and in maven 3 it's no longer possible to define different versions for compile scope and test scope. stefan
