How does PDE determine the JUnit Plug-in dependencies?

[ptziegler]

This is a weird behavior I noticed while converting one of the Platform test bundles from JUnit4 to JUnit5. I still can't wrap my head around what exactly is going on here, so maybe someone can help me make sense of this.

Let's begin with a very simple plugin depending on JUnit 4. The four OSGi plugin are there by default. By adding org.junit, this plugin as well as org.hamcrest (because it is re-exported by org.junit) are added to the dependencies and can be used within this plugin. So far so good.

If I remove org.junit, both dependencies are removed again, leading to compilation errors. This is also what I would expect.

But if I now import one of the JUnit 5 packages, the JUnit 4 bundle is re-added again. Thankfully PDE warns me about the illegal access. But just being able to resolve the type feels wrong, also because this error could've easily been disabled in the settings.

There is no direct dependency between org.junit and any of the other dependent plugins, so I don't see the reason why this would need to be included...

Does someone understand what's going on here?

[merks]

This is happening here:

eclipse.pde/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java

Lines 566 to 578 in 5dc5f26

	/**
	* Adds JUnit5 dependencies that are required at runtime in eclipse, but not
	* at compile-time or in tycho.
	*/
	private void addJunit5RuntimeDependencies(Set<BundleDescription> added, List<IClasspathEntry> entries)
	throws CoreException {
	if (!containsJunit5Dependency(added)) {
	return;
	}
	if (junit5RuntimeClosure == null) {
	junit5RuntimeClosure = collectJunit5RuntimeRequirements();
	}

Which ends up here:

eclipse.pde/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java

Lines 600 to 603 in 5dc5f26

	private static List<BundleDescription> collectJunit5RuntimeRequirements() {
	List<BundleDescription> roots = JUNIT5_RUNTIME_PLUGINS.stream().map(PluginRegistry::findModel)
	.filter(Objects::nonNull).filter(IPluginModelBase::isEnabled)
	.map(IPluginModelBase::getBundleDescription).toList();

And so org.junit is added whether you want it or not:

eclipse.pde/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java

Lines 74 to 76 in 5dc5f26

	private static final Set<String> JUNIT5_RUNTIME_PLUGINS = Set.of("org.junit", //
	"junit-jupiter-engine", // BSN of the bundle from Maven-Central
	"org.junit.jupiter.engine"); // BSN of the bundle from Eclipse-Orbit

It is the case that JDT's junit5 runtime requires org.junit:

Indeed all the underlined things would drag in org.junit.

Because of these requirements:

[ptziegler]

So the JUnit bundles have a special treatment to avoid any dependency issues when executing the tests from the IDE and this behavior is not something that would happen for "normal" bundles. That clears things up a lot.

Thank you for this very detailed explanation! 😄

[merks]

I was really curious because it was a really good question and the result in really inexplicable. 😕

[laeubi]

But if I now import one of the JUnit 5 packages, the JUnit 4 bundle is re-added again. Thankfully PDE warns me about the illegal access. But just being able to resolve the type feels wrong

I tried to improve this a bit recently and there is a "hidden" option at least if you use the JUnit Container because the corresponding UI change is stuck here:

• Add UI to select if JUnit3/4 should be enabled for JUnit Platform eclipse-jdt/eclipse.jdt.ui#1433

So the JUnit bundles have a special treatment to avoid any dependency issues when executing the tests from the IDE and this behavior is not something that would happen for "normal" bundles.

Sadly yes... with the new OSGi Test Framework Support I tried to improve the situation at least for users not bound to the old legacy way, so if your are using this feature you:

1. Add JUnit Container and disable (currently manually with specify <attribute name="vintage" value="false"/>)
2. Make sure your tests are all living in a test source folder
3. Remove all imports to JUnit from the manifest
4. Use tycho plugin-test mojo (see demo here)
5. Enjoy pure JUnit5 API without legacy stuff and confusion about wrong imports, using advanced annotation based injection of OSGi objects.