On Wed, Sep 30, 2015 at 10:32 AM, Carsten Ziegeler <[email protected]> wrote: > I suggest we update to maven bundle plugin 3 in our parent pom and make > a parent pom release.
https://issues.apache.org/jira/browse/SLING-5079 Will start a release vote once I've fixed + verified it. Robert > > 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] -- Sent from my (old) computer
