Prepare standalone build with Eclipse 2026-03, #174

[krumts]

• add a new target definition
  • use Eclipse 2026-03
  • updated BIRT to 4.23
• added a p2.inf file for the standalone build to reference the 2026-03 update site
• increased the minimal required Java version to 21 as both BIRT and the platform require it (CI build and p2.inf)

[krumts]

In the local build I get some errors from the license checker.

[INFO] --- license-tool:1.1.0:license-check (license-check) @ parent ---
[INFO] Querying Eclipse Foundation for license data for 500 items.
[INFO] Found 467 items.
[INFO] Querying Eclipse Foundation for license data for 26 items.
[INFO] Found 26 items.
[INFO] Querying ClearlyDefined for license data for 5 items.
[INFO] Found 5 items.
[INFO] License information could not be automatically verified for the following content:
[INFO] 
[INFO] maven/mavencentral/org.apache.httpcomponents.client5/httpclient5/5.6
[INFO] maven/mavencentral/org.apache.httpcomponents.core5/httpcore5-h2/5.4.1
[INFO] maven/mavencentral/org.mozilla/rhino/1.9.1

So I have to run the build with -Ddash.fail=false to get it through.
I have to understand why this is happening - we are not using these directly, and I am referring only to released Eclipse content - my expectation is that these are taken care of, but we still get an error.

I addition, I haven't changed yet the default target platform - running the build with defaults would still build with 2024-12 and an older BIRT. I'd change this later, when we are sure all things are fine with the new build.

[krumts]

I figured out the dependencies:
BIRT is bringing in mozilla rhino

org.eclipse.birt.core 4.23.0.v202602121516 requires 'osgi.bundle; org.mozilla.rhino 1.9.0'

and p2 core brings (indirectly) the apache httpclient libs

Missing requirement: org.eclipse.ecf.provider.filetransfer.httpclient5 1.1.101.v20250818-1641 requires 'java.package; org.apache.hc.client5.http [5.1.3,6.0.0)' but it could not be found
...
[ERROR]   Missing requirement: org.apache.httpcomponents.client5.httpclient5 5.6.0.v20251221-1000 requires 'java.package; org.apache.hc.core5.http2 [5.4.0,6.0.0)' but it could not be found
[ERROR]   Cannot satisfy dependency: org.eclipse.ecf.provider.filetransfer.httpclient5 1.1.101.v20250818-1641 depends on: java.package; org.apache.hc.client5.http [5.1.3,6.0.0)
[ERROR]   Cannot satisfy dependency: org.eclipse.equinox.p2.core.feature.feature.group 1.7.1000.v20260108-1444 depends on: org.eclipse.equinox.p2.iu; org.eclipse.ecf.provider.filetransfer.httpclient5 [1.1.0,2.0.0), filter=(!(org.eclipse.equinox.p2.exclude.import=true))

I would probably ask back on the licence tool how it happens, that we refer only released eclipse projects, but they bring in dependencies, which are marked as "to be vetted".
I am not sure it is an issue with the tool, it might well be that I don't understand the process well enough. But I hope to get some answers on this.

For now, I think this should not block us from merging the PR in our not released version. I would like to do so, because it will allow me to build a new version and contribute it to the Simrel repo on time for M1.

Any objections?

[krumts]

Created an issue on the dash project eclipse-dash/dash-licenses#547 to ask for help.

[jasonk000]

@krumts

Confirming, this means we have jdk21 as a minimum and can rely on and refactor with jdk21 as a minimum base from now forward? Exciting if so.

[krumts]

Confirming, this means we have jdk21 as a minimum and can rely on and refactor with jdk21 as a minimum base from now forward? Exciting if so.
@jasonk000 @kgibm

I wonder how to deal with this.

• our own code and plugins (checked some MANIFEST.MF files) are still marked to require 1.8. This is probably true for our code, but many of the dependencies require a newer Java version
• Because of the requirements for some of the dependencies, the Tycho build now requires jdk21
• The standalone MAT version based on 2026-03 requires java 21 to start

One scenario which I can imaging is to have users of the tool who are "stuck" for whatever reasons on older versions and using a mixture of an old Eclipse + MAT plugins (with lower Java requirements).
However, I don't know how realistic this is. In the past we've been very conservative with java requirements, I don't know if we have to stick to this habit.
Also java 21 is already about 3 years old, so I think it should be fine if we raise the requirement to 21 - in this case we should do it consistently - documentation, Bundle-RequiredExecutionEnvironment in the bundle manifests, requirement in the standalone product, etc...

But before we go there - @kgibm - do you see any restrictions from your (IBM side), like MAT being included in products which require an older version?

[kgibm]

I was dragging my feet on upgrading from Java 8 because as long as we compiled with Java 8, MAT could still be added using an update site into older versions of Eclipse; however, I agreed it's probably time to just move on with such legacy use cases and that already happened to Java 17 as part of https://github.com/eclipse-mat/mat/pull/137/changes#diff-a73db2d248334f37bd1d36fc8dae0fcc46127ce799ecbfa453bd64a80b1dbeb6

So I think it makes sense to just go up to Java 21 for everything.