UInfortunately, looking at what they do, it is difficult to workadound them :(

Also, I don't think the exports are being added back, given the
comments in the PR, so we should consider:

* Upgrading to Gson 2.5, which is the last version that exports those packages.
* Copy those classes in our jclouds-core tree and use them directly
(Gson is under an APache 2.0 license, so this is OK). This presents
the "upgrade/sync with upstream Gson" issues we can all imagine.
* Others?

On 30 August 2016 at 15:46, Andrew Phillips <andr...@apache.org> wrote:
>> @demobox, please correct me if I'm wrong, as I'm not an OSGi expert at
>> all.
>
>
> Me neither, unfortunately ;-) But from a quick scan I think your reasoning
> is correct.
>
>> you'll see that the "com.google.gson.internal" is now excluded from the
>
>
> That would seem like a logical step, even if it's obviously not great from a
> backwards-compatibility perspective. Given the package name, I would assume
> that these classes were never meant to be used by consumers directly, so I
> think the "right" thing to do from our perspective would be to remove our
> dependencies on them.
>
> I'm not sure how much work that would involve, though.
>
> Regards
>
> ap

Reply via email to