Remove hamcrest-core from Eclipse SDK

[HannesWell]

Since hamcrest 2.0 the hamcrest-core artifact is just an empty hull to provide metadata that redirect all references to it to the new only hamcrest 'main' artifact.
Nothing in the SDK should require hamcrest-core anymore, so it can be removed.

[merks]

I guess we can't remove it because org.junit uses the bundle name according to this recipe:

We can change the recipe and produce a new version different only by the qualifier. That seems a bit questionable.

[akurtakov]

So what is the decision here ? IMO there is no other option but to rely on qualifier only, everything else has bigger negatives.

[HannesWell]

Personally I would be fine by requiring only the joint hamcrest bundle in version 2 or later.
I hope this makes the situation easier for those relying on a re-export as currently it can be quite difficult.
But at the same time I cannot say with absolute certainty that this move will not break anyone.

I would also be fine with just qualifier change or do you think there is a chance there is another junit-4 release in the future? If yes we could simply await that.

[HannesWell]

Btw. to add a bit more context, although this is not directly related, that's an issue asking to migrate JUnit-4 to hamcrest 2.2 respectively away from hamcrest, but it is not completed and I have the impression it never will be:

• Update to hamcrest 2.2 junit-team/junit4#1741

[akurtakov]

Looks like hamcrest 3.0 is making its way in the ecosystem starting to cause more problems eclipse-jdt/eclipse.jdt.ui#1672

[pci-mthompson]

Since I got shutdown on the referenced issue above I'll chime in here. It looks like maybe at least for 2023-12 I was able to get things back to a workable state by adding this explicitly to my Oomph setup files and then doing a clean re-install.

<p2:Requirement
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:p2="http://www.eclipse.org/oomph/p2/1.0"
name="org.hamcrest"
versionRange="[2.2.0,2.3.0)"/>

[akurtakov]

So hamcrest 3.0 comes from other projects as it's not in https://download.eclipse.org/eclipse/updates/4.33/R-4.33-202409030240/plugins/ and the fault of platform is for not really strong with requirements but when we do we prevent adoption of new versions so it's a tough place to be.

[pci-mthompson]

I did try to look at PDE and diff pre/post update to see what other feature actually pulled hamcrest 3.0 into the IDE. Unfortunately I couldn't sus it out. :|

[akurtakov]

I did try to look at PDE and diff pre/post update to see what other feature actually pulled hamcrest 3.0 into the IDE. Unfortunately I couldn't sus it out. :|

https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Fviews%2Ftarget_platform_state.htm is probably good starting point.

[akurtakov]

@merks would you please rebuild the orbit junit 4 to require hamcrest 3 and with qualifier update only as we should never generate new versions(to reduce the risk of conflicting if upstream releases new version). If someone objects should propose alternative plan, delaying making decisions is only making us spin in circles and losing time.

[HannesWell]

rebuild the orbit junit 4 to require hamcrest 3 and with qualifier update

I think requiring only org.hamcrest in version 2 or later would already be sufficient.

[HannesWell]

Thank you @merks for eclipse-orbit/orbit-simrel@89150d5.

Is there a specific reason why https://github.com/hamcrest/JavaHamcrest/releases/tag/v2.2 required and not just https://github.com/hamcrest/JavaHamcrest/releases/tag/v2.1 or later?
In practice it probably doesn't make a big difference, but since this artifact is old some might appropriate as old versions as possible?

[merks]

I'll close this is favor of the new PR I created that is using the new version of org.junit.