org.eclipse.m2e.maven.runtime ships old jcl-over-slf4j-1.7.36.jar, breaking MWE2 workflow

[haubi]

So I'm upgrading to Eclipse IDE 2026-06, and it turns out that the new Complete classpath for plug-in projects breaks some MWE2 workflows here running the Xtext Generator, when org.eclipse.mwe2.maven.runtime is a dependency of the bundle containing the Xtext file, and the selected Target Platform already uses SLF4J v2 in general.

To reproduce the issue, I have created some draft PR: ssi-schaefer/lcdsl#108,
for use via Oomph Setup on Github/Launch Config DSL project, requires to refresh Oomph Modular Target after fetching the PR:

• With Eclipse IDE 2026-03, the MWE2 workflow on LcDsl.xtext works fine,
• with Eclipse IDE 2026-06, the MWE2 workflow on LcDsl.xtext breaks (when not using the Temporary workaround)

The situation in more detail:

• As of Eclipse IDE 2026-06, PDE calculates Complete classpath for plug-in projects, including all the transitive dependencies,
  unless the Temporary workaround is applied to restore previous behavior.
• M2E Maven Runtime bundle, even in 2026-06 still, ships old jcl-over-slf4j-1.7.36.jar, which is for SLF4J v1,
  despite SLF4J v2 is used for quite some time already.
• MWE2 workflow uses plain Java run configurations.

IMHO, I do see these general issues here:

• M2E: Shipping embedded jars for something-over-slf4j is not a good idea in general.
• MWE2: Plug-in Dependencies are designed for OSGi, using them in plain Java run configurations is questionable.

WDYT?

For reference, having org.eclipse.mwe2.maven.runtime bundle as dependency of the bundle containing the Xtext file, the MWE2 workflow fails with this console output:

0    [main] ERROR mf.mwe2.launch.runtime.Mwe2Launcher  - org/slf4j/impl/SimpleLoggerFactory
java.lang.NoClassDefFoundError: org/slf4j/impl/SimpleLoggerFactory
	at org.eclipse.m2e.slf4j2.provider.MavenSLF4JProvider.initialize(MavenSLF4JProvider.java:55)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:201)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:187)
	at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:511)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:497)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:446)
	at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
	at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:273)
	at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.<clinit>(AbstractWorkflowComponent.java:31)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1160)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:301)
	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newConstructorAccessor(MethodHandleAccessorFactory.java:104)
	at java.base/jdk.internal.reflect.ReflectionFactory.newConstructorAccessor(ReflectionFactory.java:200)
	at java.base/java.lang.reflect.Constructor.acquireConstructorAccessor(Constructor.java:549)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:486)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.create(Mwe2ExecutionEngine.java:158)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.inCase(Mwe2ExecutionEngine.java:107)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.xtext.util.PolymorphicDispatcher.invoke(PolymorphicDispatcher.java:303)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.internalSwitch(Mwe2ExecutionEngine.java:69)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.internalApplyAssignments(Mwe2ExecutionEngine.java:145)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.inCase(Mwe2ExecutionEngine.java:117)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.xtext.util.PolymorphicDispatcher.invoke(PolymorphicDispatcher.java:303)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.internalSwitch(Mwe2ExecutionEngine.java:69)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.inCase(Mwe2ExecutionEngine.java:83)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.eclipse.xtext.util.PolymorphicDispatcher.invoke(PolymorphicDispatcher.java:303)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.internalSwitch(Mwe2ExecutionEngine.java:69)
	at org.eclipse.emf.mwe2.language.factory.Mwe2ExecutionEngine.create(Mwe2ExecutionEngine.java:65)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:94)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:63)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Runner.run(Mwe2Runner.java:53)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.run(Mwe2Launcher.java:78)
	at org.eclipse.emf.mwe2.launch.runtime.Mwe2Launcher.main(Mwe2Launcher.java:36)
Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.SimpleLoggerFactory
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 41 more

[laeubi]

breaks some MWE2 workflows here running the Xtext Generator, when org.eclipse.mwe2.maven.runtime is a dependency of the bundle containing the Xtext file

This more looks like a mw2e bug than an m2e one (even though I'm not completely sure what org.eclipse.mwe2.maven.runtime is/does exactly it seems to use m2e internals what is nothing m2e officially supports or is pulling in it indirectly by not properly crafted dependency ranges.

The m2e runtime is especially crafted to only being used internal and in a specific context, any off-label use has to be carefully considered. Especially we can't support other usage by crafting dependencies for their needs. So without further investigations how they interact its hard to decide, simply "upgrading" won't work anyways as we have to fulfill the dependencies of maven itself and the embedded jars are not really something m2e genuinely choose/uses.

[HannesWell]

• M2E Maven Runtime bundle, even in 2026-06 still, ships old jcl-over-slf4j-1.7.36.jar, which is for SLF4J v1,
  despite SLF4J v2 is used for quite some time already.

The embedded Maven runtime is indeed different to a standard Maven 3.9 installation in that sense that it uses SLF4J-2, to be compatible to what Eclipse uses.
Consequently jcl-over-slf4j indeed should be updated to match the slf4j-api being used.

However the problem should be fixed by

• [Runtime] Embed Maven 3.10.0 #2207

because with Maven 3.10 SLF4J 2 is used by default and consequently the embedded jcl-over-slf4j jar should be updated too.

Would that be sufficient for you, if Maven 3.10 is released soon?

You could already test the change an download the archived org.eclipse.m2e.repository-2.1.0-SNAPSHOT.zip from the PR's Jenkins build, unzip it locally and use it as update-site.