Replace Javax dependencies with Jakarta 8 dependencies

[recaph]

Is your feature request related to a problem? Please describe. Request to replace Javax dependencies equivalent Jakarta dependencies. It has potential to reduce package sizes as Spring, Jackson have moved from Javax (Java 8) to Jakarta 8.

e.g. javax.xml.bind --> jakarta.xml.bind etc +--- org.zowe.apiml.sdk:zaas-client:2.14.0 | +--- org.apache.httpcomponents:httpclient:4.5.14 | | +--- org.apache.httpcomponents:httpcore:4.4.16 | | --- commons-codec:commons-codec:1.11 -> 1.15 | +--- com.fasterxml.jackson.core:jackson-annotations:2.16.1 -> 2.15.3 () | +--- com.fasterxml.jackson.core:jackson-databind:2.16.1 -> 2.15.3 () | +--- org.slf4j:slf4j-api:1.7.36 | +--- javax.xml.bind:jaxb-api:2.3.1 | | --- javax.activation:javax.activation-api:1.2.0 | +--- javax.servlet:javax.servlet-api:4.0.1 | +--- org.springframework:spring-context:{strictly [5.3.31,6.0.0[; prefer 5.3.31} -> 5.3.30 () | +--- commons-codec:commons-codec:1.16.0 -> 1.15 | --- org.zowe.apiml:api-layer-bom:2.14.0 vs e.g. | --- org.glassfish.jersey.media:jersey-media-json-jackson:2.35 | +--- org.glassfish.jersey.core:jersey-common:2.35 () | +--- org.glassfish.jersey.ext:jersey-entity-filtering:2.35 | | --- jakarta.ws.rs:jakarta.ws.rs-api:2.1.6 | +--- com.fasterxml.jackson.core:jackson-annotations:2.12.2 -> 2.15.3 () | +--- com.fasterxml.jackson.core:jackson-databind:2.12.2 -> 2.15.3 () | --- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:2.12.2 -> 2.15.3 | +--- com.fasterxml.jackson.core:jackson-annotations:2.15.3 () | +--- com.fasterxml.jackson.core:jackson-core:2.15.3 () | +--- com.fasterxml.jackson.core:jackson-databind:2.15.3 () | +--- jakarta.xml.bind:jakarta.xml.bind-api:2.3.3 (*) | +--- jakarta.activation:jakarta.activation-api:1.2.2 | --- com.fasterxml.jackson:jackson-bom:2.15.3 ()

Willingness to help Yes

[pj892031]

This type of replacement is done via this code: https://github.com/zowe/api-layer/blob/3c189204b761b2ab9ba52934f0545a8390f0f03c/build.gradle#L96-L105

Anyway, to replace those dependencies is pretty tricky. For example javax.activation API has an issue because there are libraries using V1 and others using V2. Once there are set both version from Jakarta, Gradle evaluates to use just the latest version and it stop working. It is of course possible to configure Gradle to leave both version but it has consequences. We rather decided to skip the replacement of javax.activation.

Anyway, we can try to replace the rest of the libraries mentioned above.

[balhar-jakub]

As far as I understand this replacement will be done for Version 3 of the API Mediation Layer. The preview builds of the Version 3 of the API Mediation Layer are available in JFrog repository e.g. https://zowe.jfrog.io/ui/packages/gav:%2F%2Forg.zowe.apiml:discovery-service?name=discovery-service&type=packages for discovery service and as of writing this the latest available pre-release version is 3.0.3

Is the upgrade with version 3 acceptabel for you or do you need it specficially in version 2 and if that is the case is the workaround that @pj892031 proposed above good enough for you?

[recaph]

@balhar-jakub This is different from what is being done for api layer version 3. This is for version 2 where the request is to replace Javax dependencies with Jakarta 8 dependencies that use javax imports (not jakarta).. to reduce package size..

not sure why workaround is needed when api-layer can be updated.. also not sure why grade wouldn’t work?

[pj892031]

V3 uses the new Spring and the dependencies, there is no issue with those old components (I count Cloud Gateway as the replacement of API Gateway). It is done there without any javax replacement mentioned above. Jakarta libraries are the default.

The v2 contains a few dependencies that require the old version and some that require the new one. The best example is ZUUL. It requires javax.activation and javax.servlet. In the end, both versions might be necessary and part of the package. Honestly, these libraries are pretty small and the change of JAR files is really small.

[balhar-jakub]

@recaph As explained by pj892031 above the main problem is that V2 contain components that doesn't have newer version and therefore we can't replace we may maximally add the Jakarta ones.

[balhar-jakub]

Closing the issue as we won't be able to solve it for V2 and for V3 it's solved.