Package io.kubernetes.client is split between client-java and client-java-api

[azzazzel]

The package io.kubernetes.client is split between client-java and client-java-api modules.

This makes it impossible to use the kubernetes java client in any OSGi environment. For example ApiClient client = Config.defaultClient(); throws java.lang.NoClassDefFoundError: io/kubernetes/client/ApiClient as the package io.kubernetes.client is wired from client-java module and not from client-java-api module and thus it does not contain io.kubernetes.client.ApiClient class.

This also will make it impossible to convert the jars into JMPS (Jigsaw) modules as it explicitly forbids split packages.

[brendandburns]

If we packaged client-java as a separate maven library would that fix things?

I admit I don't fully understand the details of OSGi....

[yue9944882]

i think @azzazzel is correct. but we have to value backward-compatibility over the class structure currently, the overlapping classes happen to the most critical paths in this project. (compatibility always ranks #1 for SDK library). we can probably start by copying those to a new package and deprecate the old classes for 3-ish releases. @brendandburns wdyt?

[azzazzel]

@brendanburns I'm not sure what you mean by "If we packaged client-java as a separate maven library". It is build as separate Maven library from the util folder. That is part of the problem. The same package can not be in more than one Jar file. In OSGi that is a problem at runtime (it does not prevent other things from working). If you make those JPMS (Jigsaw) modules, one will not even be able to start the application. What would help is if you merge those two into one module (single jar) but I guess that is not elegant and desired solution.

@yue9944882 you are right. Fixing this the proper way would mean backward incompatible changes. I am now trying to regenerate the code with export PACKAGE_NAME="io.kubernetes.client.swagger" to see if that would solve the problem. I almost got it to compile but for some reason there are some missing classes (for example V1PodBuilder) and I can't get tests to pass. I'm probably doing something wrong as I'm not familiar with this code base. I'll let you know if I have any progress.

[brendandburns]

fwiw, we don't guarantee non-breaking major version updates (as evidenced by the recent break between 6.0.1 and 5.0.0

So I think that it's ok to make this change as part of the 7.0.x release series, though it would be useful to understand exactly what someone would have to do to update/fix their code. Likely import a new package?

[yue9944882]

I am now trying to regenerate the code with export PACKAGE_NAME="io.kubernetes.client.swagger"

i think we can rename the package by the effort of #595. the pull is going to break compatibility anyway.. i can probably take over the pull if it keeps inactive for 2 weeks..

[yue9944882]

fwiw, we don't guarantee non-breaking major version updates (as evidenced by the recent break between 6.0.1 and 5.0.0

+1, not guaranteed but it's better if we do as best as can, isnit

[azzazzel]

... it would be useful to understand exactly what someone would have to do to update/fix their code. Likely import a new package?

I guess the best thing to do is to change the package for the generated code. I used io.kubernetes.client.swagger in my experiment but given #595 it could be io.kubernetes.client.openapi for example. Then changing/adding a package import would be the only change needed in consumers' code. While it is braking existing code, any IDE should be able to assist with the changes. You could even relatively easy build a migration tool that assists with this change.

[yue9944882]

@brendandburns #709 is taking off. how do you think about rename the package path for the generated codes in that pull together?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.