[
https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Gritsch updated JCLOUDS-1548:
------------------------------------
Description:
The issues listed in the following proposal must be seen as an approach to a
difficult problem and should by no means be understood as criticism of the
developer.
In the discussion leading up to the following merge request, GSON as a library
in use was classified as problematic. In the discussion GSON was considered in
the context of OSGi-based runtime environments and an incompatibility regarding
GSON was found.
In short, the vendor of the GSON library refuses to include further OSGI
meta-information to mark any packages of the library as public.
In order to achieve compatibility between GSON and OSGi the way was taken to
substitute package names.
At first sight a substitution of this kind (GSON is included in a separate
module) is relatively simple, which is then consumed by the actual JCLOUDS code
base (estimated complexity level 3 of 10).
However, a closer look at the JCLOUDS code base reveals that there is more than
just a pure substitution of the package name.
*Why is it necessary to access package names declared as private?*
CLOUDS extends GSON with features not provided by the original GSON library.
This leads to the following critical problems with regard to maintainability
over a long time frame.
- Corresponding GSON enhancing functions were long ago included in the source
code of JCLOUD.
- Even if you take a closer look at them, it is very difficult to understand
their function. Those responsible may have stopped further development of the
project.
Simple updates of dependencies are not possible because side effects have to be
estimated directly from the additional functions and fixed in case of
incompatibility (estimated level of complexity 8 out of 10).
The actual, to the question independent of the discussion OSGi or not, we
should clarify largely the effect of the introduced additional function really
is or whether it can not be removed.
*Here are a few examples*
- JsonBall and NullHackJsonLiteralAdapter
- Structure and classification of type adaptors in general
Further questions deal with the way GSON handles certain constellations of
data, for example the de-serialization in GSON from number to double type.
In the long run, when using a library, the quality and community of the library
used must be taken into account. Google's projects in the areas of handling
JSON-based data structures (GSON) and dependency injection (Guice) have lost a
lot of development speed and willingness to take feedback from the community.
This is my personal opinion from past projects.
*Attempted solution approach*
After the first step, the introduction into the JCLOUDS library (status:
completed) I will now work on the replacement of GSON by Jackson (status:
started). If this step should be too advanced or unconsidered I would like to
ask for feedback from other developers in the community.
was:
The issues listed in the following proposal must be seen as an approach to a
difficult problem and should by no means be understood as criticism of the
developer.
In the discussion leading up to the following merge request, GSON as a library
in use was classified as problematic. In the discussion GSON was considered in
the context of OSGi-based runtime environments and an incompatibility regarding
GSON was found.
In short, the vendor of the GSON library refuses to include further OSGI
meta-information to mark any packages of the library as public.
In order to achieve compatibility between GSON and OSGi the way was taken to
substitute package names.
At first sight a substitution of this kind (GSON is included in a separate
module) is relatively simple, which is then consumed by the actual JCLOUDS code
base (estimated complexity level 3 of 10).
However, a closer look at the JCLOUDS code base reveals that there is more than
just a pure substitution of the package name.
Why is it necessary to access package names declared as private?
CLOUDS extends GSON with features not provided by the original GSON library.
This leads to the following critical problems with regard to maintainability
over a long time frame.
- Corresponding GSON enhancing functions were long ago included in the source
code of JCLOUD.
- Even if you take a closer look at them, it is very difficult to understand
their function. Those responsible may have stopped further development of the
project.
Simple updates of dependencies are not possible because side effects have to be
estimated directly from the additional functions and fixed in case of
incompatibility (estimated level of complexity 8 out of 10).
The actual, to the question independent of the discussion OSGi or not, we
should clarify largely the effect of the introduced additional function really
is or whether it can not be removed.
Here are a few examples
- JsonBall and NullHackJsonLiteralAdapter
- Structure and classification of type adaptors in general
Further questions deal with the way GSON handles certain constellations of
data, for example the de-serialization in GSON from number to double type.
In the long run, when using a library, the quality and community of the library
used must be taken into account. Google's projects in the areas of handling
JSON-based data structures (GSON) and dependency injection (Guice) have lost a
lot of development speed and willingness to take feedback from the community.
This is my personal opinion from past projects.
Attempted solution approach
After the first step, the introduction into the JCLOUDS library (status:
completed) I will now work on the replacement of GSON by Jackson (status:
started). If this step should be too advanced or unconsidered I would like to
ask for feedback from other developers in the community.
> GSON Cleanup, GSON replacement through Jackson
> ----------------------------------------------
>
> Key: JCLOUDS-1548
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1548
> Project: jclouds
> Issue Type: New Feature
> Components: jclouds-core
> Affects Versions: 2.2.1
> Reporter: Markus Gritsch
> Priority: Major
> Fix For: 2.3.0
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> The issues listed in the following proposal must be seen as an approach to a
> difficult problem and should by no means be understood as criticism of the
> developer.
> In the discussion leading up to the following merge request, GSON as a
> library in use was classified as problematic. In the discussion GSON was
> considered in the context of OSGi-based runtime environments and an
> incompatibility regarding GSON was found.
> In short, the vendor of the GSON library refuses to include further OSGI
> meta-information to mark any packages of the library as public.
> In order to achieve compatibility between GSON and OSGi the way was taken to
> substitute package names.
> At first sight a substitution of this kind (GSON is included in a separate
> module) is relatively simple, which is then consumed by the actual JCLOUDS
> code base (estimated complexity level 3 of 10).
> However, a closer look at the JCLOUDS code base reveals that there is more
> than just a pure substitution of the package name.
> *Why is it necessary to access package names declared as private?*
> CLOUDS extends GSON with features not provided by the original GSON library.
> This leads to the following critical problems with regard to maintainability
> over a long time frame.
> - Corresponding GSON enhancing functions were long ago included in the
> source code of JCLOUD.
> - Even if you take a closer look at them, it is very difficult to understand
> their function. Those responsible may have stopped further development of the
> project.
> Simple updates of dependencies are not possible because side effects have to
> be estimated directly from the additional functions and fixed in case of
> incompatibility (estimated level of complexity 8 out of 10).
> The actual, to the question independent of the discussion OSGi or not, we
> should clarify largely the effect of the introduced additional function
> really is or whether it can not be removed.
> *Here are a few examples*
> - JsonBall and NullHackJsonLiteralAdapter
> - Structure and classification of type adaptors in general
> Further questions deal with the way GSON handles certain constellations of
> data, for example the de-serialization in GSON from number to double type.
> In the long run, when using a library, the quality and community of the
> library used must be taken into account. Google's projects in the areas of
> handling JSON-based data structures (GSON) and dependency injection (Guice)
> have lost a lot of development speed and willingness to take feedback from
> the community. This is my personal opinion from past projects.
> *Attempted solution approach*
> After the first step, the introduction into the JCLOUDS library (status:
> completed) I will now work on the replacement of GSON by Jackson (status:
> started). If this step should be too advanced or unconsidered I would like to
> ask for feedback from other developers in the community.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
