Fixing (JDK 26) build & runtime, adding regression (integration) tests

[svanteschubert]

Enables JDK 26 compilation

I have been told that it is useful to compile with the latest JDK (e.g. 26), as it warns you what tomorrow breaks (sometimes it breaks already).

Tests

Tested successfully with three JDKs on Windows & MacOS:

1. Oracle JDK 26 on two platforms (osx-x64 and win-x64)
2. Oracle JDK 11 osx-x64

Changes in pom.xml (parent)

1. Added auto-value.version property (set to 1.11.1) - keeps auto-value and auto-value-annotations on a single, consistent version.
2. Bumped auto-value from 1.6.5 to ${auto-value.version} (1.11.1) - the processor and annotations were mismatched, which broke annotation processing.
3. Added <useModulePath>false</useModulePath> - maven-compiler-plugin 3.14.0 defaults to true, which on JDK 26 caused the compiler to non-deterministically fail to resolve classes across the classpath/module-path boundary.
4. Added true - runs javac as a separate process, preventing the IDE's Java language server from racing with the in-process compiler for write access to target/classes.

Changes in protege-editor-owl/pom.xml

1. Replaced redundant <source>11</source><target>11</target> with an execution-scoped <annotationProcessorPaths> block on default-compile only - this tells javac exactly where to find the AutoValue annotation processor (needed because classpath-based discovery doesn't work reliably with this plugin/JDK combination), while keeping the default-testCompile execution free of processor path config so test classes can see production classes normally.

[svanteschubert]

Fix JDK 26 annotation processing setup

Problem

Building with JDK 26 exposed instability in compilation/annotation processing (especially around AutoValue generation), including intermittent classpath/module-path related behaviour and missing generated classes.

What changed

Aligned AutoValue artefacts to a single version via parent property:

auto-value
auto-value-annotations

Updated compiler defaults in parent maven-compiler-plugin config:

release=11
useModulePath=false
fork=true

In protege-editor-owl, configured annotation processor path for default-compile to ensure AutoValue processor is applied consistently.

This prevents mixed AutoValue versions and processor mismatches.
Avoids module-path side effects with modern JDK during Maven compile.
Makes generation of AutoValue classes reproducible in reactor builds.

Add in first commit regression integration tests for OSGi manifest import issues (make problem visible)

Runtime startup failures were caused by invalid OSGi Import-Package entries (compile-time-only/shaded packages appearing as required runtime imports). This was not previously guarded by tests.

Added integration tests that inspect built bundle manifests:

protege-editor-core/src/test/java/org/protege/editor/core/OsgiBundleManifest_IT.java
protege-editor-owl/src/test/java/org/protege/editor/owl/OsgiBundleManifest_IT.java

Wired failsafe execution and passed the built jar location via bundle.jar system property where needed.
What the tests assert

Bundle Import-Package must not contain runtime-unresolvable imports like:
autovalue.shaded...
(later refined) com.google.errorprone.annotations.concurrent

This converts a runtime OSGi resolution failure into a CI-visible regression signal.
Ensures future dependency/processor changes don’t silently reintroduce startup breakage.

[svanteschubert]

Problem

protege-desktop startup failed at runtime due to invalid OSGi/runtime dependencies in packaged bundles:

• unresolved java.applet via glassfish-corba-omgapi on modern JDKs
• fragile reflective LAF initialisation path during UI startup

Patch

• Removed org.glassfish.corba:glassfish-corba-omgapi from desktop assemblies:
  • protege-desktop/src/main/assembly/dependency-sets.xml
  • protege-desktop/src/main/assembly/protege-os-x.xml
• Hardened LAF instantiation/error handling in:
  • protege-editor-core/src/main/java/org/protege/editor/core/ui/workspace/Workspace.java

Note:
Regression ITs were committed first in a separate commit to reproduce and prove the failure before applying the fix.

[svanteschubert]

After adding integration tests, running the run script and a binary dependent on the used OS, looking for exceptions in the log (failing the test if there is one), the test fails on GitHub CI tests.

GitHub Actions runs on Linux without a real display. The desktop launcher integration tests start the packaged app in a child JVM; that process had no DISPLAY, so Swing failed while initialising the log UI (JOptionPane / JDialog), surfaced as HeadlessException and failed the “no Exception in output” check.

1. CI: Install Xvfb (“X virtual framebuffer”), which is an X11 display server that draws to memory instead of to a real monitor, keyboard, or GPU window and run xvfb-run -a mvn verify so Maven and every spawned process inherit a virtual X display—same idea as the old Travis xvfb + DISPLAY setup.
2. App: In LogManager, skip building the log dialogue when GraphicsEnvironment.isHeadless(), so static startup does not require a window server (extra safety for headless/scripted runs). showLogView() no-ops the dialogue when there isn’t one.

Summary:
CI gets a display for real GUI/agent behaviour; headless environments no longer crash on log dialogue construction.

[svanteschubert]

Summary

Recent testing revealed that while the build remains "green," the application is experiencing functional UI failures.
Specifically: Starting the run.sh on Mac with JDK 26 had thrown an exception.

The Pizza Ontology fails to load/render in the UI (not becoming the active ontology), but PR behaviour is similar to the last release from March.

Key Proposals

Feature Regression Testing: Implement a regression test suite for every (GUI) feature.
Initial Test Case: Loading the Pizza Ontology (making it local).

Technical Changes in this PR

• JDK 26 / build: Align AutoValue versions and compiler plugin settings so the project builds on newer JDKs.
• OSGi / manifests: Add Failsafe integration tests that assert bundle manifests and imports (including AutoValue shaded / runtime import regressions); refine those tests for current runtime behavior.
• OSGi packaging: Fix module-info handling so inlined module-info.class is not embedded in OSGi bundles in a way that breaks downstream javac (Felix bundle plugin / packaging tweaks in POMs).
• Desktop startup: Fixes for startup / class resolution issues uncovered by the new integration tests.
• Launchers: run.bat / run.command (and related) updated so packaged desktop launchers can accept extra JVM options (e.g. for tests/agents).
• Desktop ITs + GUI agent: DesktopLauncherScripts_IT and ProtegeGuiTestAgent — integration tests that start the assembled distribution, drive window close via a Java agent, and assert clean shutdown / logs; follow-up commits extend that behavior.
• Workspace: Adjustments tied to the launcher / shutdown / GUI test flow (refactor in Workspace.java).
• macOS / Aqua: Address reflective access warnings for the Aqua look-and-feel.
• CI / headless: GitHub Actions — xvfb + xvfb-run around mvn verify; LogManager skips building the log dialog when headless so static init does not throw HeadlessException.

Testing Environment

The changes have been verified across the following configurations:

1. MacOS (ARM): JDK 26 and JDK 11
2. Linux (Ubuntu): OpenJDK 11
3. Windows 10: JDK 26