4.16 Releng

[merks]

Tracks the release engineering activities for the 4.16 release.

[merks]

The latest nightly build is at 4.16.0 now:

https://download.eclipse.org/birt/updates/nightly/latest

@speckyspooky

Feel free to make changes toward 4.16.0, 🏁

[speckyspooky]

Thanks I will prepare my PRs.

[merks]

@wimjongman @speckyspooky @SteveSchafer-Innovent

Note that the Eclipse EPP packages for 2024-06 will require Java 21. Of course the BIRT bundles themselves could continue function also on Java 17, but I've done some preliminary investigation into getting an updated version of Derby into Orbit and that raises the same question about Java 21 requirements.

A major problem with Derby is that the artifacts at maven central:

• https://repo1.maven.org/maven2/org/apache/derby/derby/10.16.1.1/
• https://repo1.maven.org/maven2/org/apache/derby/derby/10.17.1.0/

have effectively OSGi garbage in their MANIFEST.MF

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.10.6
Created-By: 17+35-2724 (Oracle Corporation)
Bundle-Vendor: Apache Software Foundation
Bundle-Name: Apache Derby 10.16
Bundle-Version: 10.16.1000001.1901046
Bundle-ManifestVersion: 2
Sealed: true
Bundle-Activator: org.apache.derby.osgi.EmbeddedActivator
Bundle-SymbolicName: derby
DynamicImport-Package: *
Export-Package: org.apache.derby.authentication,org.apache.derby.datab
 ase,org.apache.derby.io,org.apache.derby.jdbc,org.apache.derby.vti
Class-Path: derbyshared.jar derbyLocale_cs.jar derbyLocale_de_DE.jar d
 erbyLocale_es.jar derbyLocale_fr.jar derbyLocale_hu.jar derbyLocale_i
 t.jar derbyLocale_ja_JP.jar derbyLocale_ko_KR.jar derbyLocale_pl.jar 
 derbyLocale_pt_BR.jar derbyLocale_ru.jar derbyLocale_zh_CN.jar derbyL
 ocale_zh_TW.jar

Name: org/apache/derby/jdbc/
Sealed: false

The classpath specifies jars that do not exist nested in the jar and the package exports are insufficient. Also, the source artifacts are also missing. (I have no idea why that is even allowed on Maven Central.)

In any case, it's a complete mess. In addition, the project apparently has no interest in fixing this mess even if someone contributes the fix:

apache/derby#15

So that mess is here to say.

Therefore, I think Orbit needs to consume and rebundle the direct downloads of the project, in order to produce well-formed OSGi artifacts along with their corresponding source artifacts:

• https://db.apache.org/derby/releases/release-10_16_1_1.cgi
• https://db.apache.org/derby/releases/release-10_17_1_0.cgi

Note that version 10.17.1.0 claims to fix CVE-2022-46337 and it states "10.17 does NOT support Java releases prior to Java SE 21", which I can confirm is a fact because of the version of the .classfiles.

So while Orbit could repackage 10.16.1.1, which supports Java 17, it doesn't seem sensible to repackage an older version with a known CVE. Of course if we repackage 10.17.1.0, the BIRT core runtime (at least those parts with Derby dependencies) will no longer work on Java 17. No matter what, we really must move forward from the 10.11.1.1 version sooner rather than later.

So my sense is that the only proper course of action is to move to the latest Derby version which requires Java 21.

I am interest to hear your thoughts and concerns?

[wimjongman]

Thanks for your analysis, Ed.

We ship Derby because it contains the example "classic cars" database. It is not something that we deliver because customers need to use it for their own data. Therefore, the CVE is no problem for us.

If Orbit wants to host 10.16.1.1 I guess we can use that. If not then we need to move to 21.

[speckyspooky]

Yes, yesterday evening I saw with my dev-restart that the new Java 21 was needed from eclipse.
So I'm okay if we would use Java 21 (LTS) and that we could use at the end the latest derby-version.

Thanks too for your check!

[hvbtup]

We need Derby just for the "classic cars" DB - which is very useful for sharing example reports.
I don't have an opinion regarding Java 17 or 21.