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

Reply via email to