You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <ko...@gmx.de> on 2015/08/03 14:25:52 UTC
Problem with embedding newer version of a referenced class
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
Re: Problem with embedding newer version of a referenced class
Posted by Robert Munteanu <ro...@lmn.ro>.
On Wed, Sep 30, 2015 at 10:32 AM, Carsten Ziegeler <cz...@apache.org> 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 <ju...@justinedelson.com> 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 <ko...@gmx.de> 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
> cziegeler@apache.org
--
Sent from my (old) computer
Re: Problem with embedding newer version of a referenced class
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ju...@justinedelson.com> 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 <ko...@gmx.de> 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
cziegeler@apache.org
Re: Problem with embedding newer version of a referenced class
Posted by Konrad Windszus <ko...@gmx.de>.
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 <ju...@justinedelson.com> 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 <ko...@gmx.de> 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
>>
>>
Re: Problem with embedding newer version of a referenced class
Posted by Justin Edelson <ju...@justinedelson.com>.
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 <ko...@gmx.de> 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
>
>