[JAVA: okhttp-gson, rest-assured, retrofit2] Don't generate Jackson import when serialization library is GSON

[Philzen]

This partially reverts commit 76560e3, namely anything related to generators and samples using GSON instead of Jackson.

Changes to Jackson-only generation and generator-online regarding RFC3339DateFormat are not being reverted.

Resolves #18515

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.6.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.

[wing328]

please resolve the conflicts when you've time

cc @ChaosMarc - author of the previous commit partially reverted by this PR

[Philzen]

@wing328 conflicts resolved, ready for merge 🚀

[ChaosMarc]

I'm a little late to the party, but I nevertheless wanted to share my thoughts.

The problem with adding jackson as a dependency to gson-only builds is something I tried to adress in one of my responses (#17052 (comment)) but obviously couldn't express myself clearly enough that I also think that it's a bad idea. What I didn't realize was that it would lead to compile errors 🫣 sorry for that!

@Philzen you wrote in #18515 (comment)

Though GSON is in maintenance mode, the implementation in question has recently been committed to: ... – so IMHO for GSON fanfolks this import should still be fine.

My problem with using that class was not that it's no longer maintained but that it's in an internal package that is not exposed through osgi. IMHO it's bad practice to use internal classes because they (propably) are internal for a reason. To use the class in other osgi modules you have to add (compileInclude) the dependency to every module that uses it instead of just deploying it to the osgi runtime container once and reference (implementation) it in the other modules' manifest.

[Philzen]

@ChaosMarc i wasn't aware of OSGi at all before your post, learning something new every day… cheers. Sounds important to consider for professional industry applications, so i get you.

This is now a classical target conflict, as on the other side at least two users, @winrid and @efren1villamagua have raised issues with having a Jackson dependency suddenly appearing in their stack. Although i personally just migrated a huge project away from GSON over to Jackson, becoming a huge fan along the way, i absolutely share the expectation that i'd get a GSON-only stack when using okhttp-gson.

This PR only reverted the change for those, when using any other generator, RFC3339DateFormat is still Jackson-based as you introduced it in 76560e3.

My take would be that if you work in an environment where OSGi is a thing, you probably wouldn't use GSON in the first place, and OpenApiGenerator generators come with a plethora of non-GSON flavours. What do you think?

[ChaosMarc]

Hey @Philzen, thanks for reading about OSGi. It most definitely has it's use cases in modern systems even though it is around for quite a long time.

When I started my current project we went with okhttp-gson because 1. it's the default, 2. we already had okhttp in place and 3. I personally like gson very much. But with the internal classes problem at hand and the fact that the okhttp team also struggles to keep their builds working with OSGi, I agree with you and will refrain from using this particular generator in future OSGi-based projects. I will propably go with "native" instead, which was not an option as we started out with java 8 and only recently upgraded to 11. As my current project sadly has been canceled and will be killed alltogether, we will just go with my workaround of providing the internal classes in a custom osgi module ourselves (see julman99/gson-fire#52 (comment)) until we're shut down for good 😅

Thanks again for fixing the mess I've created with my previous PR and having such a good natured conversation about the whole topic with me 👍