Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Gson, Jackson and Everit JSON Schema Validation code dependencies #6810

Closed
poikilotherm opened this issue Apr 10, 2020 · 6 comments
Closed
Assignees
Labels
Component: Code Infrastructure formerly "Feature: Code Infrastructure" Feature: None No user-facing feature in particular Type: Suggestion an idea User Role: Hackathon Participant Core developers, frequent contributors, drive-by contributors, etc.

Comments

@poikilotherm
Copy link
Contributor

poikilotherm commented Apr 10, 2020

A lot of places in the code base use the Gson or Jackson library to do JSON processing (and a bit of data binding).

These should be refactored to use Java EE JSON-P (around since EE7) and JSON-B instead, making the code base using more standards and lowering no of deps.

This is related to #4260

@pdurbin
Copy link
Member

pdurbin commented Apr 10, 2020

Related: Increasingly slow feedback loop for developers, increasingly large WAR files #5593

@poikilotherm
Copy link
Contributor Author

Lately, I came back to look into #6694 now that we are on Payara 5 and can use Jakarta JSON-B standard now. This issue should be done before.

This refactoring should cleanup the direct dependency on org.everit.json.schema, too. A good replacement would be leadpony/justify, as it uses Jakarta EE APIs only and doesn't introduce the dependencies again transitively. The outdated libs where discussed in #7218/#7248, too.

Will adapt the title accordingly.

@poikilotherm poikilotherm self-assigned this Sep 11, 2020
@poikilotherm poikilotherm added the Component: Code Infrastructure formerly "Feature: Code Infrastructure" label Sep 11, 2020
@poikilotherm poikilotherm changed the title Remove Gson and Jackson code dependencies Remove Gson, Jackson and Everit JSON Schema Validation code dependencies Sep 11, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Sep 11, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Sep 11, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Sep 11, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Sep 11, 2020
Back in the days of IQSS#2290 (2016), code for JSON serialization has been introduced. This has never been used, all DataFile objects are still serialized as JSON by util.JsonPrinter. Removing this 4 year old, completely unused code.

If used in the future again, this should be done based on Jakarta JSON-B.
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Sep 11, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Oct 24, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Oct 24, 2020
poikilotherm added a commit to poikilotherm/dataverse that referenced this issue Oct 24, 2020
@pdurbin pdurbin added Type: Suggestion an idea User Role: Hackathon Participant Core developers, frequent contributors, drive-by contributors, etc. Feature: None No user-facing feature in particular labels Oct 8, 2023
@pdurbin
Copy link
Member

pdurbin commented Oct 18, 2023

@pdurbin
Copy link
Member

pdurbin commented Mar 25, 2024

@poikilotherm in Zulip, I just saw you write this:

"I can't help it: I think we need to get rid of the JsonPrinter/JsonReader classes, as described in #6810"

I thought this issue was mostly about removing the dependencies on third-party JSON libraries (Gson, Jackson, etc.) when we already have one that comes with Jakarta EE.

It's also about removing the JsonPrinter/JsonReader classes? Should that be a separate issue?

@poikilotherm
Copy link
Contributor Author

Yeah, it might be it's own issue to split the tasks. On the other hand it is very often not easy to distinguish between these things, as there are code places where a few of the techs plus our own things mix and match.

@cmbz
Copy link

cmbz commented Aug 20, 2024

To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'.

If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment.

@cmbz cmbz closed this as completed Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component: Code Infrastructure formerly "Feature: Code Infrastructure" Feature: None No user-facing feature in particular Type: Suggestion an idea User Role: Hackathon Participant Core developers, frequent contributors, drive-by contributors, etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants