Just for completeness: This issue is solved with bnd 3.0
(https://github.com/bndtools/bnd/issues/1017
<https://github.com/bndtools/bnd/issues/1017>) and therefore also with
maven-bundle-plugin 3.0.0.
But since Sling is not yet using that, we should at least fix
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>
and invert the inclusion order of the dependencies models.impl and commons.osgi.
Konrad
> On 03 Aug 2015, at 14:52, Justin Edelson <[email protected]> wrote:
>
> Hi Konrad,
> Is it possible to just embed the necessary classes rather than the whole
> package? I think we do that in other cases and would (I think) eliminate
> this issue.
>
> Regards,
> Justin
> On Mon, Aug 3, 2015 at 8:26 AM Konrad Windszus <[email protected]> wrote:
>
>> 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
>>
>>
