Replace embedded and repackaged GSON library
authorgurkerl83 <markus_gritsch@gmx.de>
Thu, 25 Jun 2020 13:27:15 +0000 (15:27 +0200)
committerAndrew Gaul <andrew@gaul.org>
Mon, 26 Oct 2020 10:58:41 +0000 (19:58 +0900)
commitd82868cc4706006bbaa025b9eff918bbcc55ef1b
tree0621d2c845e8455e02c7e6bd50988e446d81b841
parent1cd28c93c4bba8cb75577eef2eaeabf4abdc034c
Replace embedded and repackaged GSON library

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.
13 files changed:
apis/chef/src/main/java/org/jclouds/chef/config/ChefParserModule.java
core/pom.xml
core/src/main/java/org/jclouds/json/config/GsonModule.java
core/src/main/java/org/jclouds/json/internal/DeserializationConstructorAndReflectiveTypeAdapterFactory.java
core/src/main/java/org/jclouds/json/internal/NullFilteringTypeAdapterFactories.java
core/src/main/java/org/jclouds/json/internal/NullHackJsonLiteralAdapter.java
core/src/test/java/org/jclouds/json/internal/DeserializationConstructorAndReflectiveTypeAdapterFactoryTest.java
gson/gson-bundle/pom.xml [deleted file]
gson/gson-shaded/pom.xml [deleted file]
gson/pom.xml [deleted file]
pom.xml
project/pom.xml
resources/checkstyle.xml