Bump org.eclipse.swt version due to new API

[HeikoKlare]

Follow-up for #785.

[github-actions]

Test Results

     299 files  ±0       299 suites  ±0   5m 36s ⏱️ +15s
  4 097 tests ±0    4 089 ✔️ ±0    8 💤 ±0  0 ❌ ±0 
12 203 runs  ±0  12 130 ✔️ ±0  73 💤 ±0  0 ❌ ±0 

Results for commit 6d4ae3f. ± Comparison against base commit ac0c056.

[laeubi]

@HeikoKlare I suspect this now causes the build to fail see:

https://ci.eclipse.org/releng/job/Builds/job/I-build-4.31/45/console

It might be that a bump in swt also needs bumps in the fragments here:

https://github.com/eclipse-platform/eclipse.platform.swt.binaries/blob/master/bundles/org.eclipse.swt.gtk.linux.x86_64/META-INF/MANIFEST.MF

@akurtakov can you probably advice here? I can check if I can make Tycho more patient here (as the fragment still matches the range) but wonder what was the general contract here in the past.

[laeubi]

I have now further checked this and it is indeed the problem with this p2.inf the fragment is pulled but needs the strict version:

eclipse.platform.swt/bundles/org.eclipse.swt/META-INF/p2.inf

Line 10 in f19db14

requires.2.range = [$version$,$version$]

so now this no longer matches what leads to the problem it not found anymore for the consumers (jface), so version bumps are required for all fragments as well!

[iloveeclipse]

might be that a bump in swt also needs bumps in the fragments here

Yes.

[HeikoKlare]

@laeubi Thanks for fixing the fragments versions. It would be nice to have an automated check for this implicit constraint. Maybe it will become easier to have that once the fragments are part of this repo: eclipse-platform/eclipse.platform.swt.binaries#2