[GitHub] [jclouds] nacx commented on pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22
nacx commented on pull request #75: URL: https://github.com/apache/jclouds/pull/75#issuecomment-649026516 Nope, LGTM. Thanks! 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
[GitHub] [jclouds] nacx commented on pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22
nacx commented on pull request #75: URL: https://github.com/apache/jclouds/pull/75#issuecomment-644433710 >I'm not sure if GSON really intends to keep these packages away from the outside world, or if this is just a misconfiguration. You can try submitting a merge request to GSON by exporting all packages, adding four lines to the "exportcontents" section of the bnd.bnd configuration file Due to other experiences with JSON I can't promise if a change of this kind will be accepted by the developers. After all, very few Java developers know about OSGi and the rules of the construct, developers working at Google are no exception. We tried, but unfortunately, it was rejected. The main issue here is that we can no longer afford to keep the OSGi compatibility because of the lack of expertise in the active contributor group to the project. That's why we offloaded the Karaf support to the Karaf project, and this is a remaining piece that is preventing us from modernizing the codebase. Help there is really welcome. Ideally, we should try to refactor the jclouds core to stop relying on that, or even copy the files to the jclouds codebase and keep them there, but I think we can't afford the overhead of keeping OSGi into account when the expertise is not here. 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
[GitHub] [jclouds] nacx commented on pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22
nacx commented on pull request #75: URL: https://github.com/apache/jclouds/pull/75#issuecomment-644328471 >Also need to use an older JDK to work around weak 1024-bit SSL certificates. Is this because of the certificates we use in tests? Or something spotted running live tests, or because how we configure the SSL module by default? It would be great if we could upgrade and not be tied to older JDKs. 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
[GitHub] [jclouds] nacx commented on pull request #75: JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22
nacx commented on pull request #75: URL: https://github.com/apache/jclouds/pull/75#issuecomment-644326086 There were some [gson hacks](https://github.com/apache/jclouds/tree/master/gson) we did to be able to make it OSGi friendly, as there are uses of an `internal` gson package we use that has been unexpected in newer versions of the library. That made it impossible to upgrade to newer versions of it. Basically, we shaded those packages and renamed them so we can safely use them in our codebase. Now we're in a different place, and I think we should revisit our OSGi support. We moved jclouds-Karaf to the Karaf project because we lack the expertise in OSGi and maintaining it was adding too much burden on us. Does the same apply here? Should we just undo this hack, go with standard gson and upgrade normally, and remove the OSGi compatibility from our list of responsibilities? This shading hack is something that can be done by users, or even by the Karaf project, probably in a better way, so I'd be in favour of undoing this at the expense of losing compatibility. The cost of maintaining this is too high for the current community. 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
