Set Bundle-RequiredExecutionEnvironment in native SWT fragments

[HannesWell]

Because the native SWT fragments don't have a BREE set and the I/Y-build run the build with the bree-libs profile activated, the following warning is emitted:

[INFO] --- tycho-compiler:5.0.3:compile (default-compile) @ org.eclipse.swt.cocoa.macosx.aarch64 ---
[WARNING] useJDK=BREE configured, but no BREE is set in bundle. Fail back to currently running execution environment (JavaSE-21).

This sets the BREE for all native SWT fragments (like it's already done for the SVG fragment) to avoid that warning.

In the context of eclipse-platform/eclipse.platform.releng.aggregator#3891, it might otherwise happen that the SWT native fragment will be compiled with Java-25.

This was also requested in

• Missing BREE for /org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF #3310

[github-actions]

Test Results

  182 files  ±0    182 suites  ±0   28m 56s ⏱️ + 1m 25s
4 730 tests ±0  4 707 ✅ ±0   23 💤 ±0  0 ❌ ±0 
6 854 runs  ±0  6 691 ✅ ±0  163 💤 ±0  0 ❌ ±0 

Results for commit bd6394b. ± Comparison against base commit d25ff7b.

[laeubi]

As mentioned on the other ticket, setting a BREE on a fragment likely is more harm than good and we can only hope there is some kind of conflict resolution happening.

If it is really only to fix a warning in the build, I would suggest to make Tycho smarter in case of a fragment to inherit its BREE from the host in such case.

Also the fallback is the one configured in the target so I don't see any chance why Java 25 should be used? Apart from that the useJDK=BREE is mostly useless these days anyways. As we usually have the project settings files checked in even those would determine the actual used java compliance level.

[HannesWell]

Also the fallback is the one configured in the target so I don't see any chance why Java 25 should be used? Apart from that the useJDK=BREE is mostly useless these days anyways. As we usually have the project settings files checked in even those would determine the actual used java compliance level.

Yes, I also thought about that the jdt settings are probably overriding the missing BREE in the case (just haven’t checked it in detail). If Tycho can be made smarter in this regard, I'm also fine with it.

As mentioned on the other ticket, setting a BREE on a fragment likely is more harm than good and we can only hope there is some kind of conflict resolution happening.

Not that this change is particularly important for me, but out of curiosity, what kind of conflicts do you mean exactly?
A fragment's BREE should be independent from the host and a fragment could require e.g. a higher BREE. Why would that be a problem?

[laeubi]

A fragment's BREE should be independent from the host and a fragment could require e.g. a higher BREE. Why would that be a problem?

It depends on what you call a "problem". For OSGi it is not really a problem, if the host + fragment have conflicting requirements (as they need to be merged) the fragment is simply not attached. For the user it might be a bit unfortunate on the other hand if the fragment do not work.

At least in PDE I have seen similar problem that it complains about a missing host in that case (what is rather hard to diagnose) as described here

When attaching a fragment bundle to a host bundle the Framework must perform the following steps
..
Append the Require-Capability clauses of the fragment to the Require-Capability clauses of the host

So actually now the host requires both BREEs what as said should not be a problem.. still they are not independent. I would interpret the spec that as a result e.g. a host with BREE 11 and a fragment wit BREE 21 will result in the host requiring BREE 21 as well.

Apart from that it duplicates what the host already defines, so changing the BREE would require to touch more files.