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.

[merks]

FYI, we'll be winding down the release soon with SimRel releasing June 12th. I'll lock the target platform to release/permanent sights like I did the last time and will start producing milestone builds soon. That is assuming we want to release right around (shortly after) SimRel is released?

[speckyspooky]

Sounds good for me. Do we get also the new Orbit release 4.32.0 with it and so the new Rhino version 1.17.15?

[merks]

The builds having been using that version for quite some time now:

You can see all the versions here:

https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/table.html

There was a new release of XML Beans just today...

Remember you can easily update the target platform content to the latest available using Help -> Perform Setup Tasks...

[merks]

@speckyspooky @wimjongman

The target platform currently has stable content with only a single repository that I will update and commit before producing a final milestone:

birt/build/org.eclipse.birt.target/org.eclipse.birt.target.target

Lines 143 to 149 in 9181696

	<repository location="https://download.eclipse.org/cbi/updates/license"/>
	<repository location="https://download.eclipse.org/releases/2024-06/202406121000"/>
	<repository location="https://download.eclipse.org/justj/epp/milestone/latest"/>
	<repository location="https://download.eclipse.org/justj/jres/21/updates/release/latest"/>
	<repository location="https://download.eclipse.org/tools/orbit/simrel/maven-jetty/release/12.0.9"/>
	<repository location="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/release/4.32.0"/>
	<repository location="https://download.eclipse.org/oomph/simrel-orbit-legacy/milestone/latest"/>

That repository change will not alter the binary content consumed for the target platform, but I wanted the release commit to contain repositories that can be used to reproduce the same build in the future.

Based on this, I've produced our first 4.16 milestone:

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

As such, in principle, we could produce a release the same day as SimRel next Wednesday. That schedule/goal is based purely on you and others giving me the green light for a release.

Please help set my expectations for how to best assist in this process.

[wimjongman]

I'm fine with releasing with SimRel. @speckyspooky all good for you?

[speckyspooky]

It is ok for me.
Only the time till next Wednsday is not so long to take a look into the milestone release and test some reports.

[speckyspooky]

Hi guys, good news!

I started an extrem fast check for the eclipse-designer and the integrated version of our BIRT-OSGi & -runtime version with latest JDK21 the latest Tomcat 9.0.89 Windows 11.

• Tested: eclipse-Designer & Preview: ok
• BIRT OSGi: ok based on the demo reports
• BIRT runtime: ok based on the demo reports

So yes, it gives me know a really good feeling of it.

Screen of OSGi version (start page)

Screen of runtime version (start page)

[merks]

Don’t let me pressure you. I’m here to help, not to set deadlines. That said, coordinating with SimRel is good optics.

[wimjongman]

I did a smoke test of the BIRT all in one and it works very nice. Imported a new driver and took some date from the mainframe.

[merks]

It all sounds very promising!

[merks]

@wimjongman @speckyspooky

So, just to level set here, I believe we are prepared for releasing 4.16 on Wednesday June 12th. That means the exactly binary content of

https://download.eclipse.org/birt/updates/milestone/S202406071258

will be promoted to a release.

I assume that I have a green light to do that. If someone else should review and approve, we should notify them. If there is some other channel we should use to announce this plan, we should use it.

[wimjongman]

I will post this on the channels.

[wimjongman]

I found a blocker. #1727

[merks]

There is a new release candidate waiting for final approval:

https://download.eclipse.org/birt/updates/milestone/S202406131946

[wimjongman]

+1

To the batmobile, let's go!

[speckyspooky]

+1

I'm at the batmobile and load the battery.

[merks]

Mission accomplished:

• https://download.eclipse.org/birt/updates/release/4.16.0
• https://github.com/eclipse-birt/birt/releases/tag/4.16.0

[speckyspooky]

Great Job Guys - Thanks to all !

[wimjongman]

Anyone knows how this can be resolved?

[wimjongman]

adding -Dorg.eclipse.swt.browser.DefaultType=edge to ini fixed it