Nine BaseImportTestCase failures in I-build test on Linux with Java 21 and 23 since I20241108-1800

[HannesWell]

Nine BaseImportTestCase tests fail in I-build test on Linux with Java 21 and 23 since I20241108-1800:

• https://download.eclipse.org/eclipse/downloads/drops4/I20241113-1800/testresults/html/org.eclipse.pde.ui.tests_ep434I-unit-linux-x86_64-java21_linux.gtk.x86_64_21.html
• https://download.eclipse.org/eclipse/downloads/drops4/I20241113-1800/testresults/html/org.eclipse.pde.ui.tests_ep434I-unit-linux-x86_64-java23_linux.gtk.x86_64_23.html

Locally this was not preproducible when running the tests with Java-21 on Windows.

[jukzi]

It is 9 times "Missing source attachement for entry" example:

java.lang.AssertionError: Missing source attachement for entry org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-17[CPE_CONTAINER][K_SOURCE][isExported:false]
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertNotNull(Assert.java:713)
at org.eclipse.pde.ui.tests.imports.BaseImportTestCase.assertSourceAttached(BaseImportTestCase.java:206)
at org.eclipse.pde.ui.tests.imports.BaseImportTestCase.verifyProject(BaseImportTestCase.java:189)
at org.eclipse.pde.ui.tests.imports.BaseImportTestCase.doSingleImport(BaseImportTestCase.java:129)
at org.eclipse.pde.ui.tests.imports.BaseImportTestCase.testImportFlat(BaseImportTestCase.java:83)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)

[jukzi]

Would be nice if any linux user could try to reproduce locally. The error message reads like the error could be that the 21+23 VMs just don't have any JDK 17 installed.

[iloveeclipse]

I can't see these errors locally (I see 6 other errors with all JVM's I have from 17 to 23).
I assume the JDK 21 & 23 packages installed & used in our jenkins environment do not include sources which would explain uniform error message here.

@HannesWell : didn't we recently changed images used for tests or something like that? Could one see which rpms or deb files are installed for OpenJDK? At least on RHEL there is not one but few packages needed to have a "full" JDK.

[HannesWell]

That's an interesting idea

I assume the JDK 21 & 23 packages installed & used in our jenkins environment do not include sources which would explain uniform error message here.

That could be the case. Do you have an immediate idea, how this can be verified?

We use the JDK tools provided by Eclipse CBI:
https://github.com/eclipse-cbi/jiro/wiki/Tools-(JDK,-Maven,-Ant)#eclipse-temurin

They were updated recently: https://www.eclipse.org/lists/cross-project-issues-dev/msg19971.html
This happened a few days before the failures started (altough I'm not 100% sure it started at the date mentioned above, it's the first retained I-build).

@HannesWell : didn't we recently changed images used for tests or something like that? Could one see which rpms or deb files are installed for OpenJDK? At least on RHEL there is not one but few packages needed to have a "full" JDK.

Yes, I changed from centos images to Ubuntu in eclipse-platform/eclipse.platform.releng.aggregator#2522. And it fits quite well to the timeframe of the occurance of these failures...
I tested the change before, but only for Java-17, and I don't know why I didn't notice new failures the next day.
Anyways I replayed the I-build tests for Linux and Java-21 from last night to get a confirmation or contradiction of the assumption that the os has an influence here:
https://ci.eclipse.org/releng/job/AutomatedTests/job/ep434I-unit-linux-x86_64-java21/42/

[HannesWell]

@HannesWell : didn't we recently changed images used for tests or something like that? Could one see which rpms or deb files are installed for OpenJDK? At least on RHEL there is not one but few packages needed to have a "full" JDK.

Yes, I changed from centos images to Ubuntu in eclipse-platform/eclipse.platform.releng.aggregator#2522. And it fits quite well to the timeframe of the occurance of these failures...
I tested the change before, but only for Java-17, and I don't know why I didn't notice new failures the next day.
Anyways I replayed the I-build tests for Linux and Java-21 from last night to get a confirmation or contradiction of the assumption that the os has an influence here:
https://ci.eclipse.org/releng/job/AutomatedTests/job/ep434I-unit-linux-x86_64-java21/42/

OK in that run the tests succeeded, so the container image seem to have an influence...
But the price-question is why? The JDK used should be the same since it's obtained from a shared volume.

[iloveeclipse]

But the price-question is why? The JDK used should be the same since it's obtained from a shared volume.

As said, at least on RHEL JDK consists from multiple rpms, and if some (with sources) are missing it could be still usable to start JVM but nlt enough for SDK tests that need sources attachment. I have no idea how image is created but I can imagine it "saved" space by not installing sources part of JDK.

[akurtakov]

I'll move pde.ui.tests to Java 21 in an effort to fix this.

[HannesWell]

Looks like #1527 didn't help :/

But the price-question is why? The JDK used should be the same since it's obtained from a shared volume.

As said, at least on RHEL JDK consists from multiple rpms, and if some (with sources) are missing it could be still usable to start JVM but nlt enough for SDK tests that need sources attachment. I have no idea how image is created but I can imagine it "saved" space by not installing sources part of JDK.

Do you know any commands I can run on the command line to check if this is actually the case?