WIP: continue migration to JUnit 5 (Plan A) by KrisLimbo · Pull Request #1320 · dsldevkit/dsl-devkit

KrisLimbo · 2026-04-27T05:42:18Z

Updated ddk.target file.
Directed tycho to use JUnit5.
Changed swtbot dependency to JUnit5.
Removed JUnit4 dependencies.
Removed custom JUnit4 runners.

rubenporras · 2026-04-27T05:56:15Z

          Job job = getNextJob();
          if (job == null) {
-            Assert.fail("Existing jobs did not finish after " + waitTimeout + " milliseconds: " + expectedJobs);
+            org.junit.jupiter.api.Assertions.fail("Existing jobs did not finish after " + waitTimeout + " milliseconds: " + expectedJobs); //$NON-NLS-1$ //$NON-NLS-2$


Suggested change

org.junit.jupiter.api.Assertions.fail("Existing jobs did not finish after " + waitTimeout + " milliseconds: " + expectedJobs); //$NON-NLS-1$ //$NON-NLS-2$

fail("Existing jobs did not finish after " + waitTimeout + " milliseconds: " + expectedJobs); //$NON-NLS-1$ //$NON-NLS-2$

rubenporras · 2026-04-27T05:57:45Z

    <unit id="org.eclipse.jdt.source.feature.group" version="0.0.0"/>
    <unit id="org.eclipse.platform.feature.group" version="0.0.0"/>
    <unit id="org.eclipse.platform.source.feature.group" version="0.0.0"/>
+    <unit id="org.apache.lucene.analysis-common" version="0.0.0"/>


why do we add lucene?

rubenporras · 2026-04-27T05:58:40Z

  <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
    <repository location="https://download.eclipse.org/tools/orbit/simrel/maven-osgi/release/4.39.0"/>
    <unit id="junit-jupiter-api" version="5.14.3"/>
    <unit id="junit-vintage-engine" version="5.14.3"/>


if we have fully migrated to junit 5 we should be able to remove the junit-vintage-engine, can we?

i think so too. however, for some reason - tycho is using junit5vintage. I do not know how to make tycho use jupiter, and why the tests still keep using the vintage engine, despite best effort to remove the references to junit.
For this reason, "junit-vintage-engine" still remains in the ddk target file, as the tests will return an unresolved error when I remove that entry.

rubenporras · 2026-04-27T05:59:43Z

-<stringAttribute key="org.eclipse.jdt.launching.WORKING_DIRECTORY" value="${workspace_loc:/ddk-parent}/../"/>
+    <intAttribute key="M2_COLORS" value="0"/>
+    <booleanAttribute key="M2_DEBUG_OUTPUT" value="false"/>
+    <stringAttribute key="M2_GOALS" value="clean verify -f ddk-parent/pom.xml --batch-mode --fail-at-end"/>


why do we remove the static code analysis?

this was not intended. I was running maven on local workspace with modified configuration, and i accidentally checked this in.

KrisLimbo · 2026-04-28T02:32:22Z

Current state of this PR:

For some reason - tycho is using junit5vintage.
I do not know how to make tycho use jupiter, and why the tests still keep using the vintage engine, despite best effort to remove the references to junit.
For this reason, "junit-vintage-engine" still remains in the ddk target file, as the tests will return an unresolved error when I remove that entry.
Problems with creating/injecting Eclipse UI Workbench:
com.avaloq.tools.ddk.xtext.ui.quickfix Workbench has not been created yet.
No implementation for IWorkbench was bound.
com.avaloq.tools.ddk.check.validation
com.avaloq.tools.ddk.check.formatting
com.avaloq.tools.ddk.check.core.test
com.avaloq.tools.ddk.check.core.generator
There are other test failures as well, but I think other problems are more important for now.
Removed method filters and our custom junit runners, which has implications on our system/Jenkins tests?
What I don't like about this approach is I removed the plug-in of com.avaloq.tools.ddk.xtext.test in ‎com.avaloq.tools.ddk.xtext.test/pom.xml‎. But it seems to be safe, because all it does is launch the other tests?

Updated ddk.target file. Directed tycho to use JUnit5. Changed swtbot dependency to JUnit5. Removed JUnit4 dependencies. Removed custom JUnit4 runners.

Tests have been silently reporting "Tests run: 0" since dsldevkit#1292 (2026-04-01) bumped orbit-aggregation from 2025-09 to 4.39.0. Tycho-Surefire treats zero discovered tests as success, so CI remained green while test coverage dropped to nothing. Root cause: orbit-aggregation 4.38.0+ ships every JUnit Jupiter, Platform, and Vintage IU at both the 5.x and 6.x version families simultaneously. Tycho's planner pulls in both families, so the OSGi runtime ends up with two Class<?> instances of JUnit Platform types, producing LinkageError / ArrayStoreException during test discovery (different classloaders for the same FQN). orbit-aggregation 4.37.0 (Sept 2025) is the last release that ships JUnit at a single family (5.13.4 / Platform 1.13.4) and matches Eclipse 4.34's PDE JUnit runtime bridge. Pinning to it, removing the now-redundant maven-osgi/release/4.39.0 location, and inlining the JUnit IUs at 5.13.4 / 1.13.4 restores the three JUnit-Platform-bearing classloaders to a single agreed version. Also dropped: the unused releases/2022-12 UML2 location, which was a stealth source of additional JUnit 5.9.1 / 1.9.1 IUs (DDK does not consume any UML2 features). Verified locally on macOS aarch64: 307 tests across 75 classes, 0 failures. Tycho-Surefire's auto-detection selects the junit5vintage provider given Jupiter + vintage-engine on the classpath; no providerHint override is needed. This is step 1 of a staged plan. Subsequent PRs will: step 2 - migrate remaining JUnit 4 source surface to Jupiter step 3 - drop org.junit 4.13.2 and junit-vintage-engine entirely step 4 - upgrade to JUnit 6 + Eclipse 4.39 atomically Credit: Kris Limbo's dsldevkit#1320 / dsldevkit#1321 (Plan A / Plan B) proved the JUnit 5 migration direction; both encountered the same LinkageError during diagnosis that this fix sidesteps via version alignment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

KrisLimbo · 2026-05-05T00:24:48Z

#1324 and related PRs document the way forward to fix the JUnit tests for the DDK.
According to PR#1324, the problem with this PR and PR#1321 is as follows:

Root cause: orbit-aggregation 4.38.0+ ships every JUnit Jupiter, Platform, and Vintage IU at both the 5.x and 6.x version families simultaneously. Tycho's planner pulls in both families, so the OSGi runtime ends up with two Class<?> instances of JUnit Platform types, producing LinkageError / ArrayStoreException during test discovery (different classloaders for the same FQN).

orbit-aggregation 4.37.0 (Sept 2025) is the last release that ships JUnit at a single family (5.13.4 / Platform 1.13.4) and
matches Eclipse 4.34's PDE JUnit runtime bridge.

Tests have been silently reporting "Tests run: 0" since #1292 (2026-04-01) bumped orbit-aggregation from 2025-09 to 4.39.0. Tycho-Surefire treats zero discovered tests as success, so CI remained green while test coverage dropped to nothing. Root cause: orbit-aggregation 4.38.0+ ships every JUnit Jupiter, Platform, and Vintage IU at both the 5.x and 6.x version families simultaneously. Tycho's planner pulls in both families, so the OSGi runtime ends up with two Class<?> instances of JUnit Platform types, producing LinkageError / ArrayStoreException during test discovery (different classloaders for the same FQN). orbit-aggregation 4.37.0 (Sept 2025) is the last release that ships JUnit at a single family (5.13.4 / Platform 1.13.4) and matches Eclipse 4.34's PDE JUnit runtime bridge. Pinning to it, removing the now-redundant maven-osgi/release/4.39.0 location, and inlining the JUnit IUs at 5.13.4 / 1.13.4 restores the three JUnit-Platform-bearing classloaders to a single agreed version. Also dropped: the unused releases/2022-12 UML2 location, which was a stealth source of additional JUnit 5.9.1 / 1.9.1 IUs (DDK does not consume any UML2 features). Verified locally on macOS aarch64: 307 tests across 75 classes, 0 failures. Tycho-Surefire's auto-detection selects the junit5vintage provider given Jupiter + vintage-engine on the classpath; no providerHint override is needed. This is step 1 of a staged plan. Subsequent PRs will: step 2 - migrate remaining JUnit 4 source surface to Jupiter step 3 - drop org.junit 4.13.2 and junit-vintage-engine entirely step 4 - upgrade to JUnit 6 + Eclipse 4.39 atomically Credit: Kris Limbo's #1320 / #1321 (Plan A / Plan B) proved the JUnit 5 migration direction; both encountered the same LinkageError during diagnosis that this fix sidesteps via version alignment. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

rubenporras reviewed Apr 27, 2026

View reviewed changes

KrisLimbo force-pushed the 001-acf-13681-A branch 12 times, most recently from c551216 to 7edfc07 Compare April 28, 2026 02:30

KrisLimbo force-pushed the 001-acf-13681-A branch 4 times, most recently from 5c43feb to 5cb524e Compare April 29, 2026 04:53

KrisLimbo changed the title ~~wip: update Orbit repository (1)~~ WIP: continue migration to JUnit 5 (Plan A) Apr 29, 2026

KrisLimbo force-pushed the 001-acf-13681-A branch from 5cb524e to c862f5d Compare April 30, 2026 08:09

WIP: continue migration to JUnit 5 (Plan A)

a5bb6d7

Updated ddk.target file. Directed tycho to use JUnit5. Changed swtbot dependency to JUnit5. Removed JUnit4 dependencies. Removed custom JUnit4 runners.

KrisLimbo force-pushed the 001-acf-13681-A branch from c862f5d to a5bb6d7 Compare April 30, 2026 08:34

joaodinissf mentioned this pull request Apr 30, 2026

fix: pin orbit-aggregation to 4.37.0 to restore test discovery #1323

Merged

KrisLimbo closed this May 5, 2026

KrisLimbo deleted the 001-acf-13681-A branch May 7, 2026 00:16

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: continue migration to JUnit 5 (Plan A)#1320

WIP: continue migration to JUnit 5 (Plan A)#1320
KrisLimbo wants to merge 1 commit into
dsldevkit:masterfrom
KrisLimbo:001-acf-13681-A

KrisLimbo commented Apr 27, 2026 •

edited

Loading

Uh oh!

rubenporras Apr 27, 2026

Uh oh!

KrisLimbo Apr 28, 2026

Uh oh!

rubenporras Apr 27, 2026

Uh oh!

KrisLimbo Apr 28, 2026

Uh oh!

rubenporras Apr 27, 2026

Uh oh!

KrisLimbo Apr 28, 2026

Uh oh!

rubenporras Apr 27, 2026

Uh oh!

KrisLimbo Apr 28, 2026

Uh oh!

KrisLimbo commented Apr 28, 2026 •

edited

Loading

Uh oh!

KrisLimbo commented May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	org.junit.jupiter.api.Assertions.fail("Existing jobs did not finish after " + waitTimeout + " milliseconds: " + expectedJobs); //$NON-NLS-1$ //$NON-NLS-2$
	fail("Existing jobs did not finish after " + waitTimeout + " milliseconds: " + expectedJobs); //$NON-NLS-1$ //$NON-NLS-2$

Conversation

KrisLimbo commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KrisLimbo commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KrisLimbo commented May 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

KrisLimbo commented Apr 27, 2026 •

edited

Loading

KrisLimbo commented Apr 28, 2026 •

edited

Loading