Fixed OSGI import version for Grizzly

[dmatej]

• We use 4.0.2 for build
• The range was limiting major upgrades of other projects while breaking changes in Grizzly still did not affect Jersey. Now we set just the minimal Grizzly version.
• I am not sure if Grizzly 3 is really compatible, but I am not brave enough to change it now.
• This PR blocks release of GlassFish 8.0.0, see Integrate Grizzly 5 virtual thread pool - support for virtual threads for HTTP and IIOP requests glassfish#25859

Note: I have noticed some issues with test stability (already without this change), I will try to improve it in standalone PR(s).

[dmatej]

@senivam Could you do something with branch names? It is a mess, I am not sure which branch should be the target one. Why so old branch is the default one? Should I change it to 4.0 or 4.0.0-BRANCH is the right one? Why it declares 4.0.99-SNAPSHOT version as the next snapshot? I think it would be better to follow some Maven conventions.

[jansupol]

Branch 4.0.0-Branch should be deleted, it is the release branch, from which is tag 4.0.0 created, I think.
There is branch 4.0 which does not have JPMS, and 4.0.JPMS which has it, and which is used as a main 4.0 branch with the support of JPMS.
Why do you want to restrict the grizzly to 3? Should it not be [3,6)? So that either Grizzly in GF works with Jersey?
Jersey used to have [3,4), then because of GF we updated to [3,5), so that we could integrate with whatever Grizzly comes and we do not block GF, now we probably should have [4,6).

[dmatej]

Branch 4.0.0-Branch should be deleted, it is the release branch, from which is tag 4.0.0 created, I think. There is branch 4.0 which does not have JPMS, and 4.0.JPMS which has it, and which is used as a main 4.0 branch with the support of JPMS. Why do you want to restrict the grizzly to 3? Should it not be [3,6)? So that either Grizzly in GF works with Jersey? Jersey used to have [3,4), then because of GF we updated to [3,5), so that we could integrate with whatever Grizzly comes and we do not block GF, now we probably should have [4,6).

This doesn't restrict it to 3, but the meaning is 3 or later. Note that AI gives wrong answers, surprisingly SO is correct, see: https://stackoverflow.com/questions/8353771/osgi-valid-version-ranges/8354987#8354987
I tested it with Grizzly 5.0.0-SNAPSHOT and GlassFish 8.0.0-SNAPSHOT + other projects using Grizzly. Grizzly will move faster this year and releasing every projects after every its major version doesn't make sense if these dependencies really are not affected by changes in Grizzly which could be breaking for some projects - and for some not.

See also eclipse-ee4j/glassfish#25859 - just because Grizzly releases 5, we have to release some 5 projects despite they use still the same API. With Grizzly 6 it would repeat again for no reason.

[jansupol]

Sounds ok, then. Can you rebase onto a different branch?

[dmatej]

Sounds ok, then. Can you rebase onto a different branch?

Done, I hope this branch is the right one :-)

[senivam]

@dmatej - {version}-BRANCH branches are technical branches which are being created during a release process of a particular {version}. Usually they are merged back to the branches from which the release had occured and are being deleted aftewards. Some. hovever, are not merged yet that's why you are facing the mess .
The 2.x branche corresponds to the Jakarta 8 version of Jersey and is still maintained. All changes from it are propagated to the 3.0 (Jakarta 9), 3.1 (Jakarta 10) and 4.0 (Jakarta 11) branches. The 4.0.JPMS branch in for JPMS support of the Jakarta 11 Jersey. So, everything which is in the 4.0 is also released in the 4.0.JPMS with JPMS support.

[arjantijms]

So, everything which is in the 4.0 is also released in the 4.0.JPMS with JPMS support.

Do we need the separate 4.0 branch still? Maybe just continue with 4.0.JPMS exclusively?

[senivam]

Do we need the separate 4.0 branch still? Maybe just continue with 4.0.JPMS exclusively?

@arjantijms - yes, good point, it was planned as you are saying - convert 4.0.JPMS into the 4.0 and by that replace the original 4.0 without JPMS. However, we are not 100% sure JPMS is totally fine, so that is why the original 4.0 branch is being kept.

[arjantijms]

@senivam I renamed 4.0 to backup40branch, and renamed 4.0.JPMS to 4.x