maven-surefire classpath order is different between 3.x and 4.x

[ewillink]

For Tycho 3.0.5 the classpath seen by a JUnit test broadly respects bottom up dependency order.
305.txt
Using Tycho 4.0.4 the 18 project dependencies have been moved to the start
404.txt

Similar paths are available in Temp as e.g surefire-20241223200814267_1tmp however the path is obfuscated so I present the rational paths above.

EMF's static codegen templates require overrides to re-use the EMF package name in client code hence it is necessary for the org.eclipse.ocl.examples.codegen plugin to provide a rival org.eclipse.emf.codegen.ecore.templates.model to org.eclipse.emf.codegen.ecore. Tycho 3.0.5 respected the principle of dependency first that prevents 'derived' package overrides; org.eclipse.emf.codegen.ecore preceeds org.eclipse.ocl.examples.codegen. The 'derived' OCL variant is occluded and only useable when a special purpose ClassLoader uses a explicit classpath. Tycho 4.0.4 does not respect the dependency order so normal use of the EMF package finds the OCL variant first.

Please restore Tycho 3.0.5's respect for dependency first.

[laeubi]

I'm not sure what your expectation here is and its hard to tell without a small reproducer so you should provide an integration-test to demonstrate the issue (unless we don't have a test is also not a regression but only undefined behavior).

In any case I don't think you can expect any particular classpath ordering and maven surefires itself does not guarantee a particular order beside that

1. The test-classes directory
2. The classes directory
3. The project dependencies (with all scopes)

Having conflicting ones (e.g. as your described case) are considered an error in the classpath.

[ewillink]

Surely Tycho provides the Eclipse integration for Maven? Since this problem only occurs with Tycho 4.0.4 but not 3.0.5 despite Maven, Java, Eclipse versions remaining unchanged, there is a Tycho regression. . Clearly the way in which Tycho presents the Eclipse classpath to Maven Surefire has changed. Debugging led me to discover that maven surefire is passed its class path via a boot jar in e.g. AppData\Local\Temp\surefire-20241223200814267

I agree that classpath ambiguities are an undesirable practice. But not illegal practice. I explained why EMF forced me into it. Eclipse has a well defined mechanism for ordering the classpath. Tycho 3.0.5 respects the Eclipse order. Tycho 4.0.4 breaks it.

Yes I could provide a much smaller repro, but it would just demonstrate what you already recognise as the problem. Not respecting the Eclipse classpath order to resolve class loading ambiguities usefully.

[laeubi]

Since this problem only occurs with Tycho 4.0.4 but not 3.0.5 despite Maven, Java, Eclipse versions remaining unchanged, there is a Tycho regression.

Just because something works differently does not mean it is a regression or how it works before was intended or even guaranteed.

Look for example on this recent example:

• [bp] Upgrade integration test bundles to BREE 17 #4573

There we have seen a regression, still some things "worked" until someone noticed that the "working" behavior was actually wrong. The problem with undefined behavior is that it also includes that sometimes it produce correct results, but nothing one should depend on.

Yes I could provide a much smaller repro, but it would just demonstrate what you already recognise as the problem.

I don't recognize any problem, classpath ordering is nothing we intentionally setup nor guarantee beside what written before (test classes before main classes and then all dependencies) and I see in your provided output that this is actually the case.

I explained why EMF forced me into it.

The you should ask for EMF providing better ways to archive this goal. It is of course not "illegal" but you will see probably unexpected results.