You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Geoff Macartney <ge...@apache.org> on 2020/07/06 21:16:26 UTC
Re: jclouds use of gson
Hi all,
Just copying the Apache Brooklyn community on this.
As Ignasi mentioned [2] Brooklyn uses jclouds' OSGI support. I am not
saying we need to do anything but it might be worth us at least being
aware of the ongoing discussion.
Regards
Geoff
[2] https://github.com/apache/jclouds/pull/78#issuecomment-650507931
On Mon, 6 Jul 2020 at 17:21, Robert Varga <ni...@hq.sk> wrote:
>
> On 06/07/2020 14:59, Andrew Gaul wrote:
> > A contributor recently submitted a pull request to jclouds which
> > proposes unshadowing gson, part of our efforts to modernizing our
> > dependencies:
> >
> > https://github.com/apache/jclouds/pull/78
> >
> > However, our team lacks the OSGi expertise to review this change. Could
> > someone from the Karaf team help us out? The Karaf project took over
> > maintenance of jclouds-karaf last year and we prefer not to break any
> > users:
> >
> > https://www.mail-archive.com/dev@karaf.apache.org/msg13623.html
> >
>
> Hello,
>
> I cannot contribute to an explicit review, sorry.
>
> I would suggest steering clear of 2.8.6 due to a number of OSGi
> packaging mistakes:
> https://github.com/google/gson/issues/1601
> https://github.com/google/gson/issues/1602
>
> We are using non-shaded gson-2.8.5 in OpenDaylight for a few years now
> without any issues -- the latest packaged features.xml lives here:
> https://repo1.maven.org/maven2/org/opendaylight/odlparent/odl-gson/7.0.3/odl-gson-7.0.3-features.xml
>
> Regards,
> Robert
>
Re: jclouds use of gson
Posted by Alex Heneveld <al...@cloudsoft.io>.
Thanks Geoff, and Jclouds team, and Markus for the contribution.
FWIW regretfully I'd rather jclouds *didn't* do this. Personally I
don't see benefits to Apache Brooklyn and I *do* see it increasing our
dependency hell -- as ugly as shading is, it spares us that problem.
Given that it sounds like GSON OGSi support is flaky (thanks Robert) and
the community unresponsive (no release since the issues were fixed in
2019) it seems especially unwise.
There was a suggestion that Jackson be used, instead of GSON (whether
official or forked and shaded), as the way to modernize and go
proper/clean OSGi and simplify integration. I'd +1 that.
On a side note, the use of BND here seemed nice. Would that be a
candidate for a separate PR?
Best
Alex
On 06/07/2020 22:16, Geoff Macartney wrote:
> Hi all,
>
> Just copying the Apache Brooklyn community on this.
>
> As Ignasi mentioned [2] Brooklyn uses jclouds' OSGI support. I am not
> saying we need to do anything but it might be worth us at least being
> aware of the ongoing discussion.
>
> Regards
> Geoff
>
> [2] https://github.com/apache/jclouds/pull/78#issuecomment-650507931
>
> On Mon, 6 Jul 2020 at 17:21, Robert Varga <ni...@hq.sk> wrote:
>> On 06/07/2020 14:59, Andrew Gaul wrote:
>>> A contributor recently submitted a pull request to jclouds which
>>> proposes unshadowing gson, part of our efforts to modernizing our
>>> dependencies:
>>>
>>> https://github.com/apache/jclouds/pull/78
>>>
>>> However, our team lacks the OSGi expertise to review this change. Could
>>> someone from the Karaf team help us out? The Karaf project took over
>>> maintenance of jclouds-karaf last year and we prefer not to break any
>>> users:
>>>
>>> https://www.mail-archive.com/dev@karaf.apache.org/msg13623.html
>>>
>> Hello,
>>
>> I cannot contribute to an explicit review, sorry.
>>
>> I would suggest steering clear of 2.8.6 due to a number of OSGi
>> packaging mistakes:
>> https://github.com/google/gson/issues/1601
>> https://github.com/google/gson/issues/1602
>>
>> We are using non-shaded gson-2.8.5 in OpenDaylight for a few years now
>> without any issues -- the latest packaged features.xml lives here:
>> https://repo1.maven.org/maven2/org/opendaylight/odlparent/odl-gson/7.0.3/odl-gson-7.0.3-features.xml
>>
>> Regards,
>> Robert
>>
Re: jclouds use of gson
Posted by Alex Heneveld <al...@cloudsoft.io>.
Thanks Geoff, and Jclouds team, and Markus for the contribution.
FWIW regretfully I'd rather jclouds *didn't* do this. Personally I
don't see benefits to Apache Brooklyn and I *do* see it increasing our
dependency hell -- as ugly as shading is, it spares us that problem.
Given that it sounds like GSON OGSi support is flaky (thanks Robert) and
the community unresponsive (no release since the issues were fixed in
2019) it seems especially unwise.
There was a suggestion that Jackson be used, instead of GSON (whether
official or forked and shaded), as the way to modernize and go
proper/clean OSGi and simplify integration. I'd +1 that.
On a side note, the use of BND here seemed nice. Would that be a
candidate for a separate PR?
Best
Alex
On 06/07/2020 22:16, Geoff Macartney wrote:
> Hi all,
>
> Just copying the Apache Brooklyn community on this.
>
> As Ignasi mentioned [2] Brooklyn uses jclouds' OSGI support. I am not
> saying we need to do anything but it might be worth us at least being
> aware of the ongoing discussion.
>
> Regards
> Geoff
>
> [2] https://github.com/apache/jclouds/pull/78#issuecomment-650507931
>
> On Mon, 6 Jul 2020 at 17:21, Robert Varga <ni...@hq.sk> wrote:
>> On 06/07/2020 14:59, Andrew Gaul wrote:
>>> A contributor recently submitted a pull request to jclouds which
>>> proposes unshadowing gson, part of our efforts to modernizing our
>>> dependencies:
>>>
>>> https://github.com/apache/jclouds/pull/78
>>>
>>> However, our team lacks the OSGi expertise to review this change. Could
>>> someone from the Karaf team help us out? The Karaf project took over
>>> maintenance of jclouds-karaf last year and we prefer not to break any
>>> users:
>>>
>>> https://www.mail-archive.com/dev@karaf.apache.org/msg13623.html
>>>
>> Hello,
>>
>> I cannot contribute to an explicit review, sorry.
>>
>> I would suggest steering clear of 2.8.6 due to a number of OSGi
>> packaging mistakes:
>> https://github.com/google/gson/issues/1601
>> https://github.com/google/gson/issues/1602
>>
>> We are using non-shaded gson-2.8.5 in OpenDaylight for a few years now
>> without any issues -- the latest packaged features.xml lives here:
>> https://repo1.maven.org/maven2/org/opendaylight/odlparent/odl-gson/7.0.3/odl-gson-7.0.3-features.xml
>>
>> Regards,
>> Robert
>>
Re: jclouds use of gson
Posted by Alex Heneveld <al...@cloudsoft.io>.
Thanks Geoff, and Jclouds team, and Markus for the contribution.
FWIW regretfully I'd rather jclouds *didn't* do this. Personally I
don't see benefits to Apache Brooklyn and I *do* see it increasing our
dependency hell -- as ugly as shading is, it spares us that problem.
Given that it sounds like GSON OGSi support is flaky (thanks Robert) and
the community unresponsive (no release since the issues were fixed in
2019) it seems especially unwise.
There was a suggestion that Jackson be used, instead of GSON (whether
official or forked and shaded), as the way to modernize and go
proper/clean OSGi and simplify integration. I'd +1 that.
On a side note, the use of BND here seemed nice. Would that be a
candidate for a separate PR?
Best
Alex
On 06/07/2020 22:16, Geoff Macartney wrote:
> Hi all,
>
> Just copying the Apache Brooklyn community on this.
>
> As Ignasi mentioned [2] Brooklyn uses jclouds' OSGI support. I am not
> saying we need to do anything but it might be worth us at least being
> aware of the ongoing discussion.
>
> Regards
> Geoff
>
> [2] https://github.com/apache/jclouds/pull/78#issuecomment-650507931
>
> On Mon, 6 Jul 2020 at 17:21, Robert Varga <ni...@hq.sk> wrote:
>> On 06/07/2020 14:59, Andrew Gaul wrote:
>>> A contributor recently submitted a pull request to jclouds which
>>> proposes unshadowing gson, part of our efforts to modernizing our
>>> dependencies:
>>>
>>> https://github.com/apache/jclouds/pull/78
>>>
>>> However, our team lacks the OSGi expertise to review this change. Could
>>> someone from the Karaf team help us out? The Karaf project took over
>>> maintenance of jclouds-karaf last year and we prefer not to break any
>>> users:
>>>
>>> https://www.mail-archive.com/dev@karaf.apache.org/msg13623.html
>>>
>> Hello,
>>
>> I cannot contribute to an explicit review, sorry.
>>
>> I would suggest steering clear of 2.8.6 due to a number of OSGi
>> packaging mistakes:
>> https://github.com/google/gson/issues/1601
>> https://github.com/google/gson/issues/1602
>>
>> We are using non-shaded gson-2.8.5 in OpenDaylight for a few years now
>> without any issues -- the latest packaged features.xml lives here:
>> https://repo1.maven.org/maven2/org/opendaylight/odlparent/odl-gson/7.0.3/odl-gson-7.0.3-features.xml
>>
>> Regards,
>> Robert
>>