geomacy commented 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 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:
us...@infra.apache.org


Reply via email to