remove internal ISO8601Utils dependency

[ChaosMarc]

This PR removes the last dependency to com.google.gson.internal.* packages by copying ISO8601Utils.java to this project's source code. The file itself was already copied to gson from the Jackson databind library (see https://github.com/google/gson/blob/main/gson/src/main/java/com/google/gson/internal/bind/util/ISO8601Utils.java). I have used the latest version to date: https://github.com/FasterXML/jackson-databind/blob/2.16/src/main/java/com/fasterxml/jackson/databind/util/ISO8601Utils.java

This change is needed as the internal gson packages (where ISO8601Utils has been copied to) have been excluded from the exposed packages in osgi environments since gson version 2.8.6 (see this related issue for more information: #13169 in which the same package imports were already removed from gson-fire)

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.1.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@bbdouglas, @sreeshas, @jfiala, @lukoyanov, @cbornet, @jeff9finger, @karismann, @Zomzog,@lwlee2608, @martin-mfg

[ChaosMarc]

Another option would be to add the jackson databind dependency when using okhttp or retrofit with gson, but that felt even more wrong to me

[martin-mfg]

Hi @ChaosMarc

Another option would be to add the jackson databind dependency when using okhttp or retrofit with gson, but that felt even more wrong to me

To me this actually seems like the better solution. It's less code in OpenAPI Generator to maintain and allows us to get future updates/fixes to the ISO8601Utils class by simply referencing a new jackson databind version.

Why does this feel more wrong to you?

[ChaosMarc]

Hi @martin-mfg

To me this actually seems like the better solution. It's less code in OpenAPI Generator to maintain and allows us to get future updates/fixes to the ISO8601Utils class by simply referencing a new jackson databind version.

As ISO8601Utils has been deprecated in jackson-databind for some time now, I don't think there will be any more updates to it, but you're right, if there were some changes, this way you'd get them more easily.

Why does this feel more wrong to you?

Because my goal of this PR was to minimize (transitive) dependencies and by using jackson-databind you'd add a XML processing library as a dependency to generated code that uses a JSON processing library (gson). For starters this seems very counter-intuitive to me. I'm coming from a java/gradle project that runs in an osgi environment and am not a big fan of including (transitive) dependencies in my projectes jar files themselves but provide them to the osgi container myself. When adding jackson-databind as a dependency to the generated code my own modules need it to run during runtime. Therefore I have to provide it to the container and it's dependencies like jackson-core and jackson-annotation and THEIR depenendencies until everything is satisfied. After that I have have a full blown xml processing setup just to use some single deprecated util class from it to use in my json processing. I can make this work for my project, but I don't think it's the best idea in general.

If you want can update this PR with your suggested changes (I've already tested it locally) or open another one

Edit: see https://github.com/OpenAPITools/openapi-generator/compare/master...ChaosMarc:openapi-generator:master-2?expand=1 for the much smaller diff of your proposed change

[martin-mfg]

Thanks for your reply - and your PR :)

On the one hand, it seems jackson-databind is already on the class path anyway. (I only checked for samples/client/echo_api/java/okhttp-gson/pom.xml though.) So we wouldn't need to include a new dependency for now to get it from jackson-databind.

On the other hand, FasterXML/jackson-databind#1786 mentions that ISO8601Utils should be replaced by StdDateFormat. Which behaves slightly different though, as discussed in that issue. And in #7304 we did this replacement already, with a configuration for StdDateFormat that (hopefully?) works for us.

With this new information, it seems the best solution is migrating to StdDateFormat where it hasn't been done yet. What do you think?

[ChaosMarc]

Thank you for FasterXML/jackson-databind#1786. I tried to find an official statement for the successor of ISO8601Utils in the past, but didn't find the issue you mentioned.

I agree that switching to StdDateFormat seems the right way to go and will try to modify my PR in that regard

[ChaosMarc]

I've updated this PR to use StdDateFormat instead of copying or using the depreciated util class. I hope I managed to change everything like it was meant to be.

edit: there are some tests failing. Some of the generated sample projects need the additional jackson-databind dependency. should I use the official com.fasterxml.jackson.core:jackson-databind dependency or org.openapitools:jackson-databind-nullable like in petstore-okttp-gson

[martin-mfg]

Please use com.fasterxml.jackson.core:jackson-databind in these cases.

[ChaosMarc]

@martin-mfg This took me longer than I anticipated, but I think I'm done now 😅

First I tried using StdDateFormat for parsing and formatting but failed in creating formatted datetime strings if they were in in the UTC Timezone. In those cases StdDateFormat ends the formatted strings with +00:00 instead of the expected Z (2011-12-03T10:15:30+01:00 is fine, but your tests want 2011-12-03T10:15:30Z instead of 2011-12-03T10:15:30+00:00). I couldn't find a configuration to change this so I went with StdDateFormat only for parsing and used java.time.format .DateTimeFormatter.ISO_OFFSET_DATE_TIME for the formatting. I also tried to use DateTimeFormatter.ISO_OFFSET_DATE_TIME for parsing to remove the jackson dependency completely but it fails at least for date-only strings (like "2023-11-24").

For rest-assured and retrofit2 I had to move the jackson-databind dependency from a condition to always be required.

I also updated RFC3339DateFormat to not extend ISO8601DateFormat anymore. Instead it now extens DateFormat directly and implements the methods format and parse in the way I previously described.

[martin-mfg]

Thanks again for your work.
Let's wait for wing328 to have a final review and merge this PR.

[ChaosMarc]

@wing328 happy new year. did you find some time to look over this PR?

[wing328]

@ChaosMarc just merged it. Sorry for the delay in reviewing.

[winrid]

This generates a client that does not compile for me. I don't have any need for supporting java.sql.Date but now I have to import jackson for stuff to compile. For now we are going to use a custom mustache template which is the old version I guess.