Project re-structure for Jakarta support which is not compatible with Java8

[yue9944882]

trafficstars

We're going to do a critical project re-structure to obtain the new Jakarta annotation support by bumping openapi-generator from v4.3.1 to v6.6.0. The work will consist of the following steps:

1. Re-generate the models/APIs based on v.4.3.1 on the existing client-java module (like we did in the past): https://github.com/kubernetes-client/java/pull/2923
2. Rename the current client-java module to client-java-legacy, and this legacy module will be java8 compatible for those users sticking with java8. https://github.com/kubernetes-client/java/pull/2928, it will maintained in a separated branch named master-java8
   • Modify GH action to only build the legacy modules for JDK8
3. Having a CR in the gen repo to support overriding useSingleRequestParameter configuration to solve the pain from maintaining long list of separate parameters: https://github.com/kubernetes-client/gen/pull/257
4. Re-generate a new module named client-java using v6.6.0 generator and package name to be io.kubernetes.client.openapi.v2, the new module will obtain jatarta annotation support but only compatible to java11+ JDK versions
5. Merge back manual changes in we previously made in JSON to both client-java and client-java-legacy module
6. Support fluent builder for both the legacy and the new module
7. Move the other extended module from legacy module to the new module so we can progressively deprecate the legacy one

@brendandburns what do you think about the plan above?

[brendandburns]

Looks good to me, I think that the only thing that is missing is how we will make the fluent bindings work in the new version/package.

[brendandburns]

I was thinking about this some more in the context of the PR that you sent.

I think that it may be easier to maintain this as a git branch rather than cloning the code.

[brendandburns]

We did this in the javascript library with the 0.x and 1.x branches.

[codefromthecrypt]

I'm wondering what the rationale is for a separate branch for master-java8, as that introduces a lot of maintenance.

Should we not compile to java8 with JDK11 instead? Basically drop support for using JDK 8 to compile the project, while retaining the ability to run on java 8?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.