[java gen] - Support generated annotations

[fabiobrz]

Description

The changes are related to those in #4348
The generator will now generate the expected annotations, i.e. those defined in io.fabric8.generator.annotation, the same ones that a reverse CRD generation from the Java model take into account.

Fix #4384

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

I can suash the commits as soon as this is ready for merge or even earlier in case we agree on it.
FYI @andreaTP, CC @manusa

[andreaTP]

A couple of minor cleanups, but this is great work! Thanks a ton @fabiobrz !

[fabiobrz]

Hi @andreaTP and @manusa - latest changes pushed to address your review comments. Let me know if you spot anything else.

BTW - can I squash the commits now?

[andreaTP]

Thanks a lot for this contribution @fabiobrz !
LGTM!

[fabiobrz]

Thanks a lot for this contribution @fabiobrz ! LGTM!

Welcome @andreaTP - squashing my commits then!

[fabiobrz]

Hi @manusa - one e2e tests failed after I squashed my commits, although it was green already before that.
I'll try to re-spin a run, but IMHO it should be an intermittent/random failure.

[andreaTP]

cc. @manusa looking forward for your input here 🙏

[manusa]

LGTM, thx!

I think it would be worth adding a note on the the breaking changes list, since some users who might be using the Java generator, rely on the javax validation annotations that are no longer added.

This also raises the question: as a developer relying on the java generator, how can I further transform the generated code to replace fabric8-fabric8 specific annotations with annotations that might be usedeful for my project (e.g. javax.validation)?

[andreaTP]

worth adding a note on the the breaking changes list

I agree, just want to note that the Java-Generator is still in "preview", so breaking changes are fine there.
Maybe 6.2 is a good candidate to get the Java Generator out of the Preview?

Regarding your additional question, we should come up with something for sure ... 😓 I have a couple of half-baked ideas in mind but am not convinced yet, open to suggestions!

[fabiobrz]

I think it would be worth adding a note on the the breaking changes list, since some users who might be using the Java generator, rely on the javax validation annotations that are no longer added.

Hi @manusa - thanks for your feedback, will do.

This also raises the question: as a developer relying on the java generator, how can I further transform the generated code to replace fabric8-fabric8 specific annotations with annotations that might be usedeful for my project (e.g. javax.validation)?

I've been discussing this shortly with @andreaTP as well last week.
Yesterday I was thinking about it and I came to the conclusion that maybe we'd want to create one issue for supporting the generation of validation constraints annotations per each framework type.

This would allow for them to be worked on asynchronously and for the support to different framework to be released in steps.
Maybe we could start with supporting the javax.validation.* as a PoC, in order to evaluate whether the proposal is actually fitting.

WDYT? CC @andreaTP

[andreaTP]

for supporting the generation of validation constraints annotations per each framework type

This is an interesting idea, but I'm afraid to add this complexity to the core java-generator project.

I'm thinking about adding the possibility to arbitrarily customize the generated code before emitting it, offering a Visitor or Traverse pattern that can perform generic post-processing.

On top of that mechanism, we can implement separate plugins for each of the features we want to support, and they can possibly live in separate repositories/projects.

Note: the described mechanism might be used as a foundation to implement optimizations, such as class deduplication and similar.

[fabiobrz]

for supporting the generation of validation constraints annotations per each framework type

This is an interesting idea, but I'm afraid to add this complexity to the core java-generator project.

I'm thinking about adding the possibility to arbitrarily customize the generated code before emitting it, offering a Visitor or Traverse pattern that can perform generic post-processing.

On top of that mechanism, we can implement separate plugins for each of the features we want to support, and they can possibly live in separate repositories/projects.

Note: the described mechanism might be used as a foundation to implement optimizations, such as class deduplication and similar.

Thanks @andreaTP!
+1 on loading the implementation dynamically, i.e. prepare the foundation for plugins. It makes sense to me and I actually thought of it as well, in relation to the complexity increase for the core module.

[fabiobrz]

I think it would be worth adding a note on the the breaking changes list

Done, should be ready fr merge as soon as CI checks pass.

FYI @manusa

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[andreaTP]

Thanks!