fix: [OpenAPI] Introduce openapi-core-apache module

[rpanackal]

Context

SAP/cloud-sdk-java-backlog##464

Fix scope:

• Introduce a new module without spring in dependency tree
  • Move all apache specific code and tests out
• Modify template to fix imports
• Apply in openapi-api-apache-sample

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Documentation updated [Java 5.27.0] Apache OpenAPI client cloud-sdk#2366
• Release notes updated

[rpanackal]

What consequence does this additional module for the sake of spring optionality have ?

Surely, the import namespace will be affected. Apart from that the bigger concern is new duplicated classes.

• RFC3339DateFormat (package-private)
• OpenApiRequestException - will include in the list of breaking changes in AI SDK on migration to apache client

[CharlesDuboisSAP]

There are still changes in openapi-core and openapi-generator compared to before your first Apache PR. Ideally there are no changes

[newtork]

(Question/Major)

This is a breaking change for users that may have depended on the new classes, right?
Is this an accepted risk?

[rpanackal]

My assumption is that risk is very low since the newly released classes were never advertised, therefore this shouldn't be a problem.

I can also remove the apiclient package and extract the classes within to the outer package com.sap.cloud.sdk.services.openapi. I original intention was to we keep the same module structure as in openapi-core.
This will not entirely solve the issue because classes in core package eg: OpenApiResponse, OpenApiRequestException will still be affected.

Do you have a different take?

[CharlesDuboisSAP]

Could the exception be renamed to not be a breaking change anymore?

[newtork]

Regarding "breaking changes", I agree to Roshin's low-risk estimation.

I was thinking about the class names-/renames for OpenApiResponse and OpenApiRequestException: If both were kept with the same FQN / namespace like the legacy RestTemplate flavored classes, then the migration effot for users would be very low. Unfortunately if both class-pairs had same FQN, no user could ever use the two openapi-core
artifacts as dependencies in one project. I think the later limitation is relatively heavy. Therefore...

I would keep your current approach with dedicated namespace for Apache flavor. This will offer highest level of compatibility at the cost low migration effort for users deliberately wanting to go from RestTemplate to Apache flavor.

[newtork]

I'm okay with not putting everything Beta.

No more spring