I suggest we update to maven bundle plugin 3 in our parent pom and make a parent pom release.
Carsten Am 30.09.15 um 09:20 schrieb Konrad Windszus: > 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 >>> >>> > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
