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