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

  188 files  ±0    188 suites  ±0   27m 29s ⏱️ + 1m 19s
4 732 tests ±0  4 709 ✅ ±0   23 💤 ±0  0 ❌ ±0 
6 861 runs  ±0  6 698 ✅ ±0  163 💤 ±0  0 ❌ ±0 

Results for commit 7b95fd5. ± Comparison against base commit a6d7c66.

♻️ This comment has been updated with latest results.

[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.

[HannesWell]

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.
[...]
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.

To me this all is expected and logical.

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

That's the only down-side. But IMO not a too big problem since the BREE's are only updated rarely.

On the other hand it would allow to define different BREEs per OS, e.g. in case we move the SWT impl for one OS earlier to use FFM than the other. Not saying we should do that for a longer time, but for a short time such period could exist.

[HeikoKlare]

Just as a quick documentation of my view on this after some private discussion: I see good arguments against and in favor of adding BREEs to fragment. While they make more explicit the requirement of every fragment (which can differ from the one of the host), they introduce additional maintenance effort. So I don't think there is any strong argument in either of the directions.
Since we may see fragments with different BREEs in the near future and since we are currently starting into a transition phase from Java 21 to Java 25, it seems reasonable to me to make explicit the BREE for every fragment, such that the individual requirements are directly visible, which is why I am slightly in favor of merging this PR.