Replace substituted GSON package names with those provided from the vendor.
Reduce OSGi-metadata declaration of core-module because the artificial package org.jclouds.json.gson.internal was removed.
Remove the Gson module its children Gson bundle, and Gson shaded.
Remove duplication conflict and check-style rules due to the removal of the internal Gson module.
Add maven repository where a custom version of the Gson library gets hosted, which exports all packages.
Remove particular repository
Remove the declaration of the repository that serves a custom build GSON version. The build uses GSON in its original form of the vendor, which gets distributed through the standard distribution channel. The identifiers for group, artifact, and version correspond to the latest stable release of GSON.
Integrate GSON library in Clouds Core Bundle
The change contained in the commit puts the GSON library into the classpath of the JClouds core module.
After several tests with Karaf and Karaf JClouds, especially if the Maven identifier matches the original GSON library, there are only a limited number of ways to keep the deployment effort low.
Specifically, Karaf has a set of predefined Maven repositories that can be easily customized. The order in which a particular repository is resolved into the customized GSON library is more difficult. In normal OSGi applications, which do not have such a management function, I imagine this configuration to be more complicated. Sure, a unique identifier would help, but then we are back to step 1.
Although I honestly don't like to see this kind of approach in a codebase I'm working with, there are not many alternatives to the main aspect of deployment mentioned above.
Maybe the approach can still ease the problem in the short term. In a further mid-term step, however, this problem must be addressed in general.
* JCLOUDS-1166: Relocate the gson internal packge to be able to keep using it
* Fixes
* Fix import order and shaded jar
* More fixes
* Proper dependency configuration
* Fix typos
* Bring back duplicate exclusions
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
* Improves extension namespace configuration to use Guice multibindings
so each provider can cleanly provide their own namespaces.
* Fixes the HPCloud Compute volume attachment namespace and adds the
corresponding live tests.
* Fixes the Rackspace CloudServers UK volume attachment namespace.
This commit also improves some internal behavior related to the
bootstrap configuration generation, and deprecated some methods that
will be removed in upcoming versions.
* Removes all methods that return the bootstrap DataBag or the raw
configuration json to return the BootstrapConfig object instead.
* Deprecates all methods that provide support for old Chef versions.
* Formats the Enterprise Chef provider according to the jclouds
formatting guidelines.
* Deprecates the ChefContext view. That view is not an abstraction and
only provides access to the ChefService. It can be obtained from the
ChefApi itself.
Andrew Gaul
Andrew Gaul
gurkerl83
Ignasi Barrera
andreaturli
rongallagher
Josef Cacek
Oliver Gondža
Adrian Bravo
Chris Custine
Jeremy Daggett
William Chu
akorompai
Adrian Cole
Adrian Cole