OCI SDK 2.x is incompatible with Helidon 3

[barchetta]

This is a tracking issue.

Helidon 3 supports MicroProfile 5 and Jakarta 9+. In those versions the Java package names for Jakarta components changed from javax to jakarta introducing an incompatibility.

Helidon 3 uses JAX-RS 3.0.0 (jakarta package names) and the corresponding Jersey implementation. OCI SDK 2.19.1 uses JAX-RS Client 2.1.6 (javax package names) and the corresponding Jersey implementation. Therefore the OCI SDK is incompatible with Helidon 3 applications and any application that uses JAX-RS 3.

The issue has been reported to the OCI SDK team. See oracle/oci-java-sdk#371

Helidon 2 uses JAX-RS Client 2.1.6 so no issues there.

[mricken]

In oracle/oci-java-sdk#371 , I have a little example that successfully uses the OCI Java SDK (with shaded Jakarta 2) and then uses Jakarta 3.0.0 and Jersey 3.0.4 to make an HTTP request.

@barchetta , please take a look if that could be a viable work-around.

[ljnelson]

Mostly taking notes here:

(For clarity and posterity: there is no such thing as Jakarta 2 or Jakarta 3.0.0. I believe the intent of the prior comment is to show the interoperability of the all-inclusive OCI shaded jar file, which shades/aliases its dependencies on, among other things, Jakarta RESTful Web Services version 2.1, and Helidon's support on the master branch for Jakarta RESTful Web Services version 3.0.)

My understanding is that in Helidon's code that integrates with the OCI Java SDK where we would previously use, say, javax.ws.rs.client.ClientBuilder (just an example typed off the cuff) we would instead use shaded.com.oracle.oci.javasdk.javax.ws.rs.client.ClientBuilder.

Additionally, any existing Helidon 2.5.x user who had, say, an OCI ClientConfigurator would have to change that code as well (this is independent of Helidon).

Further, we would instruct users to manually download and manually install the shaded jar as documented in the OCI SDK documentation, since as of last check this jar file does not exist in Maven Central.

(It also seems to me that any CI/CD setup, Helidon's or a customer's, will need to do this as well on each run unless there's an easier way that I'm not thinking of so there may be some devops-style work here too.)

Next we'll need to make sure our end users understand that in this setup they'll have to use the full 96MB shaded jar, even though they're probably only using one or two services out of it, because there aren't shaded versions of the individual OCI service jars. Either that or maybe there's some way to programmatically break it into pieces while manually installing it into the local Maven repository.

[ljnelson]

More notes: @mricken had previously offered to release the shaded jar into Maven Central. I've pinged him again in oracle/oci-java-sdk#371 to see if that can happen. I'd quite obviously much rather just fetch a dependency from Maven Central rather than unzipping an artifact, extracting the shaded jar, pre-populating a local Maven repo with it, etc. etc. etc.

[romain-grecourt]

Given the timeframe, we have to work-around the unavailability of the new shaded in Maven Central.

• Isolate the OCI maven modules under a profile
• Activate the profile in the relevant build scripts (etc/scripts/*.sh)
• Edit etc/scripts/build.sh to download and install the jar file(s) in the local maven repository

[arjav-desai]

• We have deprecated our Gen 2/Native OCI integration in 2.x and need to remove it from 3.0 once this change in.
• We have updated our oci vault example to use this new approach in 2.x but need to update other examples i.e. object storage and ATP to this new approach as well.
• Update docs and README to reflect this change.

All of the above will be done as part of #4480