Update the Orbit repository by KrisLimbo · Pull Request #1292 · dsldevkit/dsl-devkit

KrisLimbo · 2026-03-19T02:59:30Z

No description provided.

rubenporras · 2026-03-19T05:35:21Z

    <unit id="org.eclipse.lsp4j.sdk.feature.group" version="0.0.0"/>
  </location>
+  <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
+    <repository location="https://download.eclipse.org/tools/orbit/simrel/maven-osgi/2025-09"/>


can we use here 2026-03 as well?

done. I used orbit-aggregation/release/4.39.0 which should be the same as 2026-03.

rubenporras · 2026-03-19T05:37:09Z

-    <unit id="org.apache.commons.lang" version="2.6.0.v20220406-2305"/>
-    <unit id="org.apache.commons.logging" version="1.2.0.v20180409-1502"/>
-    <unit id="org.apache.log4j" version="1.2.24.v20221221-2012"/>
    <unit id="org.mockito.mockito-core" version="4.8.1.v20221103-2317"/>


can we also take the mockito from the new orbit?

rubenporras · 2026-03-19T05:41:16Z


  // org.eclipse.osgi needed for NLS
  // org.apache.logging.log4j needed for logging in generated StandaloneSetup
-  private static final List<String> REQUIRED_BUNDLES = newArrayList("org.eclipse.xtext.xbase.lib", "org.eclipse.xtend.lib", "org.eclipse.emf.ecore", "com.avaloq.tools.ddk.check.core", "com.avaloq.tools.ddk.check.runtime.core", "com.avaloq.tools.ddk.check.lib", "com.avaloq.tools.ddk.xtext", "org.eclipse.xtext", "org.eclipse.osgi", "org.eclipse.xtend", "org.eclipse.core.runtime", "org.eclipse.xtext.xbase", "org.apache.logging.log4j");


I think we should be able to remove this class as part of the removal of the check project for customers. Can you check that, and if so drop it first in the other tictket?

at this point I am not sure if we can safely remove this. to me it looks like it is also test project manager for the ddk automated tests.

rubenporras · 2026-03-25T10:36:16Z

 com.avaloq.tools.ddk.check.typing,
 com.avaloq.tools.ddk.check.util,
 com.avaloq.tools.ddk.check.validation
-Import-Package: org.apache.logging.log4j,


why do we change from import package too require bundle in all the plugins?

I was encountering Eclipse startup issues when trying to deploy the DDK features (i.e. export DDK plugin on host and reboot) on an ASMD workspace. [Debug log here:] (https://github.com/user-attachments/files/26257056/Debug_Log.txt)
Similar to apache/logging-log4j2#2655
It seems that ProviderUtil.lazyInit was locking up because it could not find a list of providers, so I decided
to change to require bundles to make sure that log4j.core gets loaded first before log4j.api.

But maybe there's a better way to do this?

It seems that locking up of ProviderUtil.lazyInit was caused in the ASMD workspace, when the require-bundle log4j.api gets loaded first before log4j.core.
I removed all require-bundle entries referring to logging.log4j in the ASMD target and moved them all to import-package section. Looks like the trouble with the startup issues disappeared.

rubenporras · 2026-03-26T07:40:32Z

 Require-Bundle: org.eclipse.xtext,
 org.eclipse.xtext.xtext.generator,
 org.eclipse.xtext.util,
+ org.apache.logging.log4j.core,


The org.apache.logging.log4j.core bundle is the implementation and should only be a dependency of the bundle that configures logging, not of every bundle that simply logs. Depending on core everywhere creates an unnecessary tight coupling to the implementation.

Can you revisit the commit to remove the dependency on org.apache.logging.log4j.core from most places?

I removed these changes adding entries to require-bundle and limiting changes to import-package instead.
The changes look okay with my testing until now.

rubenporras

The org.apache.logging.log4j.core bundle is the implementation and should only be a dependency of the bundle that configures logging, not of every bundle that simply logs. Depending on core everywhere creates an unnecessary tight coupling to the implementation.

Can you revisit the commit to remove the dependency on org.apache.logging.log4j.core from most places?

rubenporras · 2026-03-30T09:35:02Z

- org.eclipse.jdt.internal.ui.text,
- org.apache.log4j
+Import-Package: org.eclipse.jdt.internal.ui.text,
+ org.apache.log4j, org.apache.logging.log4j


should this not be

Suggested change

org.apache.log4j, org.apache.logging.log4j

org.apache.logging.log4j

```?

rubenporras · 2026-03-30T09:35:22Z

 com.avaloq.tools.ddk.check.ide.contentassist.antlr.internal
-Import-Package: org.apache.log4j,
- org.apache.logging.log4j
+Import-Package: org.apache.log4j, org.apache.logging.log4j


should this not be ```suggestion
Import-Package: org.apache.logging.log4j

rubenporras · 2026-03-30T09:36:26Z

 Bundle-Version: 17.2.0.qualifier
 Bundle-Vendor: Avaloq Group AG
 Bundle-RequiredExecutionEnvironment: JavaSE-21
+Import-Package: org.apache.logging.log4j


move import package to line 23 to keep order?

rubenporras · 2026-03-30T09:36:55Z

@@ -25,8 +25,7 @@ Require-Bundle: org.eclipse.xtext;visibility:=reexport,
 com.avaloq.tools.ddk.check.core,
 org.eclipse.xtext.xbase.lib
 Import-Package: org.apache.log4j,


should org.apache.log4j not be removed?

rubenporras · 2026-03-30T09:38:03Z

@@ -30,11 +30,11 @@ Export-Package: com.avaloq.tools.ddk.check.ui.test,
 com.avaloq.tools.ddk.check.ui.test.util,
 com.avaloq.tools.ddk.check
 Import-Package: org.slf4j, org.apache.log4j,


same, I do not comment the rest of the PR to not repeat in unecessarily.

done.

However, there remains some MANIFEST.MF where I cannot remove org.apache.log4j as import.
The following Activator classes are Xtext generated, and based on my understanding, the latest Xtext version
still uses log4j, so I cannot use Log4j 2 for these at this point.

CheckcfgActivator (com.avaloq.tools.ddk.checkcfg.ui)
ExportActivator (com.avaloq.tools.ddk.xtext.export.ui)
FormatActivator (com.avaloq.tools.ddk.xtext.format.ui)
ExpressionActivator (com.avaloq.tools.ddk.xtext.expression.ui)
HelloworldActivator (com.avaloq.tools.ddk.sample.helloworld.ui)
ScopeActivator (com.avaloq.tools.ddk.xtext.scope.ui)

Also FormatValueConverterService (com.avaloq.tools.ddk.xtext.format) uses org.eclipse.xtext.conversion.impl.IDValueConverter that has dependency on Log4J 1.x, so that also stays
at this point.

rubenporras · 2026-03-31T06:39:38Z

@@ -1,5 +1,5 @@
 /*
- * generated by Xtext
+ * generated by Xtext 2.27.0.M3


rubenporras

can you remove the file with the comment change from the PR?

Tycho-Surefire reports `Tests run: 0` as exit code 0, so a broken test discovery yields a green build with no tests run. PR dsldevkit#1292 went undetected for ~30 days for this reason: orbit-aggregation 4.39.0 introduced JUnit 5.x and 6.x simultaneously, breaking JUnit Platform discovery, and CI happily reported pass. Add two safeguards to verify.yml's maven-verify job: 1. After the build step (with `if: always()` so it runs even after failures), aggregate `tests=` across all surefire-reports/TEST-*.xml and fail the job when the total is below a floor of 300. The current baseline is 357 tests; the floor accommodates expected churn while still catching catastrophic regression. 2. Always upload all `**/target/surefire-reports/**/*.xml` as a CI artifact, not only the workbench .log on failure. Reviewers can now inspect actual test counts and individual failures from green runs without having to re-run locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Step 4 of the plan (JUnit 5.13.4/Platform 1.13.4 -> 6.0.3 + Eclipse 4.34 -> 4.39) is currently blocked by dual-version JUnit pollution in Eclipse 4.39's PDE chain - same architectural shape as PR dsldevkit#1292's silent-zero, with the JUnit 5.14 and 6.0 families coexisting in the OSGi runtime and producing ArrayStoreException at test discovery. This commit captures four iterations of failed attempts, the verified diagnosis from the runtime config.ini, the specific upstream bundles requiring JUnit 5.14 (jdt.junit5.runtime, swtbot junit5 feature), and three candidate paths for unblocking when resumed. Most promising near-term path: replace pde.feature.group in the target with a curated bundle list that omits both jdt.junit5.runtime and jdt.junit6.runtime, since Tycho's own junit6 OSGi fragment provides the test launcher. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Tycho-Surefire reports `Tests run: 0` as exit code 0, so a broken test discovery yields a green build with no tests run. PR dsldevkit#1292 went undetected for ~30 days for this reason: orbit-aggregation 4.39.0 introduced JUnit 5.x and 6.x simultaneously, breaking JUnit Platform discovery, and CI happily reported pass. Add two safeguards to verify.yml's maven-verify job: 1. After the build step (with `if: always()` so it runs even after failures), aggregate `tests=` across all surefire-reports/TEST-*.xml and fail the job when the total is zero. A precise zero-check targets the "discovery broke" failure mode without baking in a floor that would need maintenance as the test count drifts. 2. Always upload all `**/target/surefire-reports/**/*.xml` as a CI artifact, not only the workbench .log on failure. Reviewers can now inspect actual test counts and individual failures from green runs without having to re-run locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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>

Tycho-Surefire reports `Tests run: 0` as exit code 0, so a broken test discovery yields a green build with no tests run. PR dsldevkit#1292 went undetected for ~30 days for this reason: orbit-aggregation 4.39.0 introduced JUnit 5.x and 6.x simultaneously, breaking JUnit Platform discovery, and CI happily reported pass. Add two safeguards to verify.yml's maven-verify job: 1. After the build step (with `if: always()` so it runs even after failures), aggregate `tests=` across all surefire-reports/TEST-*.xml and fail the job when the total is zero. A precise zero-check targets the "discovery broke" failure mode without baking in a floor that would need maintenance as the test count drifts. 2. Always upload all `**/target/surefire-reports/**/*.xml` as a CI artifact, not only the workbench .log on failure. Reviewers can now inspect actual test counts and individual failures from green runs without having to re-run locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…IfNecessary call XtextBuildTrigger.scheduleFullBuild() invokes buildScheduler.scheduleBuildIfNecessary(projects) - single arg, no IBuildFlag varargs - but the test verified the call with two matchers: eq(projects) and ArgumentMatchers.<IBuildFlag[]>any(). Mockito 5.x treats the second matcher as expecting a second explicit argument, not "varargs may be empty", so verify reports an argument-count mismatch: Wanted: scheduleBuildIfNecessary([], <any>); Actual: scheduleBuildIfNecessary([]); The test passed under Mockito 4.x where vararg `any()` matched zero or more vararg invocations. This isn't introduced by step 1's 5.21->5.19 patch bump; both are strict. Master has had Mockito 5.x in scope since orbit-aggregation 4.39 (PR dsldevkit#1292), but tests being silent-zero (Tycho-Surefire reporting `Tests run: 0` as success) hid the failure. Step 1 restores test discovery, which surfaces this latent mismatch and makes the test fail deterministically (verified locally: 307 tests, 1 failure on this exact assertion). Drop the second matcher on both verify sites (the never() check and the positive verify); they now match the production single-arg call. The IBuildFlag import is no longer needed. Bundled in PR dsldevkit#1323 so its "restored 307 tests" claim lands green; splitting would ship the orbit-pin PR with a known-failing test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Tycho-Surefire reports `Tests run: 0` as exit code 0, so a broken test discovery yields a green build with no tests run. PR dsldevkit#1292 went undetected for ~30 days for this reason: orbit-aggregation 4.39.0 introduced JUnit 5.x and 6.x simultaneously, breaking JUnit Platform discovery, and CI happily reported pass. Add two safeguards to verify.yml's maven-verify job: 1. After the build step (with `if: always()` so it runs even after failures), aggregate `tests=` across all surefire-reports/TEST-*.xml and fail the job when the total is zero. A precise zero-check targets the "discovery broke" failure mode without baking in a floor that would need maintenance as the test count drifts. 2. Always upload all `**/target/surefire-reports/**/*.xml` as a CI artifact, not only the workbench .log on failure. Reviewers can now inspect actual test counts and individual failures from green runs without having to re-run locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Tycho-Surefire reports `Tests run: 0` as exit code 0, so a broken test discovery yields a green build with no tests run. PR dsldevkit#1292 went undetected for ~30 days for this reason: orbit-aggregation 4.39.0 introduced JUnit 5.x and 6.x simultaneously, breaking JUnit Platform discovery, and CI happily reported pass. Tycho-Surefire writes no TEST-*.xml when discovery yields zero, so a file-existence check on `**/target/surefire-reports/TEST-*.xml` suffices to catch the silent-zero failure mode. The step runs with `if: always()` so it fires even after build failures. Verified empirically: master (orbit-4.39.0, silent-zero) produces 0 TEST-*.xml; the check correctly fails. Working state (orbit-4.37.0, 357 tests) produces 81 TEST-*.xml; check passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

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>

…IfNecessary call XtextBuildTrigger.scheduleFullBuild() invokes buildScheduler.scheduleBuildIfNecessary(projects) - single arg, no IBuildFlag varargs - but the test verified the call with two matchers: eq(projects) and ArgumentMatchers.<IBuildFlag[]>any(). Mockito 5.x treats the second matcher as expecting a second explicit argument, not "varargs may be empty", so verify reports an argument-count mismatch: Wanted: scheduleBuildIfNecessary([], <any>); Actual: scheduleBuildIfNecessary([]); The test passed under Mockito 4.x where vararg `any()` matched zero or more vararg invocations. This isn't introduced by step 1's 5.21->5.19 patch bump; both are strict. Master has had Mockito 5.x in scope since orbit-aggregation 4.39 (PR #1292), but tests being silent-zero (Tycho-Surefire reporting `Tests run: 0` as success) hid the failure. Step 1 restores test discovery, which surfaces this latent mismatch and makes the test fail deterministically (verified locally: 307 tests, 1 failure on this exact assertion). Drop the second matcher on both verify sites (the never() check and the positive verify); they now match the production single-arg call. The IBuildFlag import is no longer needed. Bundled in PR #1323 so its "restored 307 tests" claim lands green; splitting would ship the orbit-pin PR with a known-failing test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Tycho-Surefire reports `Tests run: 0` as exit code 0, so a broken test discovery yields a green build with no tests run. PR #1292 went undetected for ~30 days for this reason: orbit-aggregation 4.39.0 introduced JUnit 5.x and 6.x simultaneously, breaking JUnit Platform discovery, and CI happily reported pass. Tycho-Surefire writes no TEST-*.xml when discovery yields zero, so a file-existence check on `**/target/surefire-reports/TEST-*.xml` suffices to catch the silent-zero failure mode. The step runs with `if: always()` so it fires even after build failures. Verified empirically: master (orbit-4.39.0, silent-zero) produces 0 TEST-*.xml; the check correctly fails. Working state (orbit-4.37.0, 357 tests) produces 81 TEST-*.xml; check passes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

rubenporras reviewed Mar 19, 2026

View reviewed changes

KrisLimbo force-pushed the master branch 6 times, most recently from eaf957e to 9cb947c Compare March 25, 2026 07:08

KrisLimbo requested a review from rubenporras March 25, 2026 09:43

rubenporras reviewed Mar 25, 2026

View reviewed changes

rubenporras reviewed Mar 26, 2026

View reviewed changes

rubenporras requested changes Mar 26, 2026

View reviewed changes

KrisLimbo force-pushed the master branch from 9cb947c to 16e948c Compare March 30, 2026 07:46

build: update the Orbit repository

7b20062

KrisLimbo force-pushed the master branch 2 times, most recently from 0ac4ff4 to 29f183f Compare March 30, 2026 08:36

KrisLimbo requested a review from rubenporras March 30, 2026 09:02

rubenporras reviewed Mar 30, 2026

View reviewed changes

rubenporras requested changes Mar 30, 2026

View reviewed changes

KrisLimbo force-pushed the master branch 2 times, most recently from bcacad3 to 99159ab Compare March 31, 2026 03:51

KrisLimbo requested a review from rubenporras March 31, 2026 05:36

rubenporras reviewed Mar 31, 2026

View reviewed changes

rubenporras requested changes Mar 31, 2026

View reviewed changes

build: update the Orbit repository

e67168b

KrisLimbo force-pushed the master branch from 99159ab to e67168b Compare March 31, 2026 09:07

KrisLimbo requested a review from rubenporras March 31, 2026 09:21

rubenporras approved these changes Mar 31, 2026

View reviewed changes

KrisLimbo merged commit c2e83ba into dsldevkit:master Apr 1, 2026
3 checks passed

joaodinissf mentioned this pull request Apr 30, 2026

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

Merged

This was referenced Apr 30, 2026

chore: drop JUnit 4 from target and bundle manifests #1326

Merged

feat: upgrade to JUnit 6 + Eclipse 4.39 (simrel 2026-03) #1327

Merged

	org.apache.log4j, org.apache.logging.log4j
	org.apache.logging.log4j
	```?

Conversation

KrisLimbo commented Mar 19, 2026

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 Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

rubenporras left a comment

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!

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!

rubenporras left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

KrisLimbo Mar 26, 2026 •

edited

Loading