Build o.e.equinox.compendium.tests and o.e.equinox.region.tests

[HannesWell]

This PR was originally created as eclipse-equinox/equinox.bundles#22 and is now moved to this repository due to the merge of the equinox.framework and equinox.bundles repository.

---

The tests in o.e.equinox.compendium.tests and o.e.equinox.region.tests are not obsolete and therefore should be build.

The tests in o.e.equinox.region.tests were disabled as part of Bug 470000 that had the goal to reduce/remove the dependencies to aspectj.

@tjwatson explained in eclipse-equinox/equinox.bundles#19 (comment) that the tests could function even without aspectj in the platform by using corresponding mocks.
For now I suggest to simply disable failing tests and to fix them later.
The reason is I would like the build to function with all projects in the repository. This way we can later fully leverage Tycho-pomless and don't have to list each module to build.

[github-actions]

Unit Test Results

     25 files       25 suites   11m 52s ⏱️
2 149 tests 2 093 ✔️ 55 💤 1 ❌
2 193 runs  2 137 ✔️ 55 💤 1 ❌

For more details on these failures, see this check.

Results for commit aec6a2e.

♻️ This comment has been updated with latest results.

[akurtakov]

Do you plan to finish this one?

[HannesWell]

Do you plan to finish this one?

Yes I do. But at the moment I'm stuck, because when I build equinox locally on my windows computer the build/tests pass (I have commented out the launcher fragments/features and the other tests to speed up the build).

If you use Linux, can you try if the the build succeeds on your computer?

[tjwatson]

I have RHEL and can take a look this week.

[laeubi]

If this helps, and we think its good to test on different OS because equinox contains OS specific behaviour, we can setup a matrix build for equinox with windows/linux/mac(?) like I recently did for SWT.

[HannesWell]

If this helps, and we think its good to test on different OS because equinox contains OS specific behaviour, we can setup a matrix build for equinox with windows/linux/mac(?) like I recently did for SWT.

For this case it would at least help to check if the failure is OS specific or if some magic is happening at my computer that the tests pass.
But in general I think this would be beneficial as well.

[HannesWell]

Looks like the tests are not executed now and therefore don't fail. Furthermore there are many errors during compilation like the following in multiple modules. I wonder why the build doesn't fail because of them:

[INFO] --- tycho-compiler-plugin:3.0.0-SNAPSHOT:compile (default-compile) @ org.eclipse.equinox.ds.tests ---
[INFO] Compiling 18 source files to /home/jenkins/agent/workspace/equinox_master/bundles/org.eclipse.equinox.ds.tests/target/classes
Failed to init Classpath for jar file /home/jenkins/agent/workspace/equinox_master/bundles/org.eclipse.equinox.ds.tests/target/scr_test/tb1.jar-classes
java.nio.file.NoSuchFileException: /home/jenkins/agent/workspace/equinox_master/bundles/org.eclipse.equinox.ds.tests/target/scr_test/tb1.jar-classes
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
	at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
	at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
	at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
	at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1264)
	at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:709)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:243)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:172)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:186)
	at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:201)
	at org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar.initialize(ClasspathMultiReleaseJar.java:38)
	at org.eclipse.jdt.internal.compiler.batch.FileSystem.<init>(FileSystem.java:235)
	at org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3495)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4741)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1802)
	at org.eclipse.tycho.compiler.jdt.JDTCompiler.compileInProcess(JDTCompiler.java:370)
	at org.eclipse.tycho.compiler.jdt.JDTCompiler.performCompile(JDTCompiler.java:123)
	at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:414)

[iloveeclipse]

I wonder why the build doesn't fail because of them

Because they only printed out, see eclipse-jdt/eclipse.jdt.core#239
I've stumbled over the code that silently ignored IO errors and added printouts because it was clear it will break messy build files.

To fail the build, you could try to set
-Dorg.eclipse.jdt.propagate_io_errors=true

[HannesWell]

I wonder why the build doesn't fail because of them

Because they only printed out, see eclipse-jdt/eclipse.jdt.core#239 I've stumbled over the code that silently ignored IO errors and added printouts because it was clear it will break messy build files.

To fail the build, you could try to set -Dorg.eclipse.jdt.propagate_io_errors=true

Thank you for the hint!
Maybe that explains the failure only on Jenkins before. So I think we should first ensure every works fine respectively fix it if not and then enable that property.

[akurtakov]

Do you plan to rebase and finish this one?

[HannesWell]

Do you plan to rebase and finish this one?

Thanks for the heads up. I still think this would be good to have (the more tests the better).
Lets see if the different platforms-tell a difference. I'll try to continue on this in the test days.

[github-actions]

Test Results

  726 files  + 63    726 suites  +63   1h 17m 16s ⏱️ + 3m 42s
2 284 tests + 73  2 181 ✅ +17   58 💤 +11  0 ❌ ±0   45 🔥 + 45 
7 010 runs  +233  6 692 ✅ +58  176 💤 +33  0 ❌ ±0  142 🔥 +142 

For more details on these errors, see this check.

Results for commit cf9b4b5. ± Comparison against base commit 5810f68.

♻️ This comment has been updated with latest results.

[HannesWell]

The tests are now running again (I configured to skip their execution when replacing pom.xml files with pom-less, just like it was before).
But the tests are still failing in the CI.
Have to investigate further...

[akurtakov]

This seems to require manual rebase now.

[laeubi]

@HannesWell is this still of interest?

[HannesWell]

This seems to require manual rebase now.

Done.

@HannesWell is this still of interest?

Since more tests are usually always better I think it still would be good to have this.
Maybe the full build+test execution on all platforms now helps to identify the issues.