Hi, in https://issues.apache.org/jira/browse/SLING-4779 <https://issues.apache.org/jira/browse/SLING-4779> we had a discussion about how to leverage a class from the bundle Commons OSGi 2.3 while still leaving the dependency at 2.2. The outcome was to use the approach listed in http://njbartlett.name/2014/05/26/static-linking.html <http://njbartlett.name/2014/05/26/static-linking.html> to embed one package from Commons OSGi in Sling Models Impl (but not export it, of course).
There is a drawback with that approach, related to the way how the maven-bundle-plugin and bnd works internally. Actually if you depend on both Sling Models Impl (1.2) and Commons OSGi (2.2) in your own bundle you might end up having an import-package statement with the wrong version range [2.3, 3) instead of [2.2, 3). This is because bnd figures out the version range by looking at the compile class path and just looks at the first package (and extracting the version in this case from its package-info). If the first dependency on the class path is now Sling Models Impl, bnd implicitly assumes, that the package is exported from the dependency (without looking at the manifest). I opened a bug at bnd on that: https://github.com/bndtools/bnd/issues/1017 <https://github.com/bndtools/bnd/issues/1017>. Should we do anything about it now in the Sling code base until the bug of bnd is fixed upstream. Probably just stripping the package-info.class from org.apache.sling.commons.osgi in Sling Models Impl would be enough, but then we can no longer use the automatism of “Conditional-Package”. This issue would affect right now Sling Mock (https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml <https://github.com/apache/sling/blob/trunk/testing/mocks/sling-mock/pom.xml>) because that one depends first on org.apache.sling.models.impl and only after that on org.apache.sling.commons.osgi. At least that we should fix. Do you have any other idea on how to fix that? Thanks, Konrad
