Nebula 3.2.0 releng

[wimjongman]

Releng for release 3.2.0

[wimjongman]

Anyone knows where this comes from?

[merks]

From this?

https://github.com/eclipse/nebula/blob/master/.github/workflows/maven.yaml

[merks]

@wimjongman

I asked about this and it was suggested that the scanning is code because of this configuration

https://github.com/EclipseNebula/.eclipsefdn/blob/9ed684fe553bcc57f1d57d685a6f7ff9f804f067/otterdog/eclipsenebula.jsonnet#L29

The problem appears to be that the scanner is running with an older version of Java than is required by the scanner libraries. But I'm not sure we can influence that anywhere so I think the IT staff needs to help:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5363

• Issue Fixed

[merks]

@HannesWell @wimjongman

I had strange problem with my Nebula installation where Oomph was disabled because of a Nebula dependency wiring problem. Unfortunately I didn't record the error and created a new installation that worked fine. In any case, it make me start to wonder about these package requirements with bundle-version constraints. In particularly it struck me that I couldn't imagine how they are represented in the p2 metadata. It turns out that they are not expressed in the p2 metadata:

So the bundle will happily install but then presumably fail to wire properly. That's certainly not ideal, but I suppose more informative than class loader errors...

But now it also seems of concern that the bundle versions are very poorly maintained. I.e., here the version last change in was in 2017, but we've made what are effectively breaking changes for some consumers:

That's definitely not a good thing but not so easy to fix at this point in time...

[HannesWell]

In any case, it make me start to wonder about these package requirements with bundle-version constraints.

They are legal according to the OSGi spec, although only used seldomly:
https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module.importpackage

bundle-version - A version-range to select the bundle version of the exporting bundle.
The default value is [0.0.0, ∞). See Semantic Versioning.
In the case of a fragment bundle, the version is from the host bundle.

But personally I usually use the strategy to only use Import-Package if the package is exported with a version. If packages of a bundle are exported without version I usually use Require-Bundle (although in general using Import-Package is preferred for various reasons).

So in this case, since SWT exports it's packages without version I would just use Require-Bundle: org.eclipse.swt. Or is there a specific reason to only import it's packages?

[merks]

As I alluded to the other day, some of these widgets are intended to work with RAP/RWT which also exports the SWT packages:

But here the bundle version is 4.x, so the bundle-version constraint will exclude that the RAP bundle. Furthermore, the changes that were made to the real SWT have not been realized as corresponding changes in RAP. So I think the RAP support is now "completely broken". Maybe no consumers remain who actually care about that...