[jira] [Commented] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson
[ https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220606#comment-17220606 ] Markus Gritsch commented on JCLOUDS-1548: - The discussion about this issue is happening on Github, in the conversation of the feature branch https://github.com/apache/jclouds/pull/78. > 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 > Labels: dependency > 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)
[jira] [Commented] (JCLOUDS-1548) GSON Cleanup, GSON replacement through Jackson
[ https://issues.apache.org/jira/browse/JCLOUDS-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17143739#comment-17143739 ] Andrew Gaul commented on JCLOUDS-1548: -- [~gurkerl83] Thanks for raising this! We are aware how jclouds usage of the gson library challenges users and I raised this as one of the dependencies to fix in 2.3.0: https://lists.apache.org/thread.html/rab068ec72653993b5336ebf9325ba1e357b2eba96d5fb87c0de1f091%40%3Cuser.jclouds.apache.org%3E However, our team lacks the background in OSGi and time to fix this properly. We would gladly consider an alternate approach if you can suggest a pull request. > 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)
