[Backport] [2.x] Fix GA workflow that publishes Apache Maven artifacts (#2625)

[reta]

Description

Fix GA workflow that publishes Apache Maven artifacts

Issues Resolved

Backport of #2625 to 2.x

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[reta]

We use JDK-11 baseline for 2.x

[ylwu-amzn]

I see this PR https://github.com/opensearch-project/ml-commons/pull/2625/files using java 21
So 2.x doesn't support 21?

[reta]

It does, and we build 2.x with 11 / 17 / 21, but main (3.x) is different- it has 21 baseline and the minimum JDK it can be built is 21, thanks @ylwu-amzn

[ylwu-amzn]

cool, so this is for minimum JDK version ?

[reta]

correct, 11 is better in this case - we are 100% the produced artifacts are compliant

[dhrubo-os]

So I have a confusion here:

We usually merge code in Main branch first, right? Let's say, I added a method in my code which works only in JDK 21 and I merged the code in main and then found the issue while backporting this to 2.x branch?

What will be my action item? Finding a suitable method which works for jdk 11 too? Or skip the integ failure for 11 & 17?

This doesn't seem like developer friendly experience to me?

@reta do you have any suggestion on this?

[reta]

Thanks @dhrubo-os

We usually merge code in Main branch first, right? Let's say, I added a method in my code which works only in JDK 21 and I merged the code in main and then found the issue while backporting this to 2.x branch?

Yes

What will be my action item? Finding a suitable method which works for jdk 11 too? Or skip the integ failure for 11 & 17?

Yes, you have to change a code to be compatible with JDK-11 baseline

This doesn't seem like developer friendly experience to me?

You are free to use only JDK-11 compatible APIs in main which basically means you won't be able to use any new language or library features. This is 100% your (== maintainers) choice.

[dhrubo-os]

@reta Thanks for your reply.

You are free to use only JDK-11 compatible APIs in main which basically means you won't be able to use any new language or library features.

Yeah exactly. In that case what's the point of using JDK 21 baseline, if I have to use JDK 11 feature/compatible apis eventually?

This is 100% your (== maintainers) choice.

I'm curious to know what do you guys do in Core? What's the best practice?

[reta]

Yeah exactly. In that case what's the point of using JDK 21 baseline, if I have to use JDK 11 feature/compatible apis eventually?

@dhrubo-os the motivation for the change itself is provided in the issue (opensearch-project/OpenSearch#10745) that is linked to ml-commons one. TLDR; it is driven by components we depend upon.

I'm curious to know what do you guys do in Core? What's the best practice?

We don't have this experience yet (the core will be the last in line to update otherwise we'll break the builds of the plugins / components that have not been moved to JDK-21 baseline yet). But every single project which I am aware of is doing some work while backporting to the older maintenance branches: the work is either manual or automated.

[dhrubo-os]

I see, thanks for your explanation.