[GitHub] [jclouds] geomacy edited a comment on pull request #78: Replace embedded and repackaged GSON library

[GitBox <gi...@apache.org>]

geomacy edited a comment on pull request #78:
URL: https://github.com/apache/jclouds/pull/78#issuecomment-716041056


   hi @nacx, about 
   > jclouds needs to be able to upgrade to newer gson versions, and this is the cleanest approach we've had so far to achieve that. If restructuring needed to accommodate the change imposes some changes in downstream projects such as karaf-jclouds integration or Brooklyn, then let it be and get those fixed as well. I think we have been very careful of not breaking stuff and bringing everyone to the same page, but we can't be blocked forever on this and pinned to the old gson library.
   
   I don't disagree with this, and I do think this PR is a great bit of work that looks like a good step forward for jclouds. I'm not opposing it, just trying to understand the implications for downstream, and what issues it might cause. 
   
   @gurkerl83 I didn't really understand your [response](https://github.com/apache/jclouds/pull/78#issuecomment-715242490) to @ahgittin above about 2.8.5 vs 2.8.6, especially
   > My estimation of using a secondary library of GSON in an OSGi stacked application is to pin its version to 2.8.5 in a JDK 8 environment.
   
   With this PR, as you showed [above](https://github.com/apache/jclouds/pull/78#issuecomment-652886362), jclouds will export the gson APIs, at v2.8.6. I can't understand how your users could then use gson at any different version [1]. 
   
   A question for everyone - about the known problems with 2.8.6: what do you think of Andrew @gaul's suggestion [above](https://github.com/apache/jclouds/pull/78#issuecomment-714821651), of staying with 2.8.5 for now? Are there any problems with it that you want to get away from? Or capabilities introduced by 2.8.6 that you want to use in the near future?
   
   In particular, do I understand it right that [google/gson#1601](https://github.com/google/gson/issues/1601) will force your downstream users to use Java 9+ with jclouds once this PR is merged?  I suppose it's hard to know what proportion of your users are still on older versions of Java?
   
   -----
   [1] footnote: well, in an OSGI environment you might have a bundle that could ignore the 2.8.6 from jclouds and use instead, say, 2.8.5, but I expect it could only do that if it didn't itself need to use jclouds.
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org