Too many dependencies in PDE container org.eclipse.pde.core.requiredPlugins

[trancexpress]

Regression from: #2218

An example problem: eclipse-jdt/eclipse.jdt.ui#2830

There is an abnormal number of plug-ins on the classpath now. E.g. org.eclipse.jdt.debug.tests had ~25 entries in the container before. It now has ~230.

E.g. looking at one plug-in that has no place on the classpath of org.eclipse.jdt.debug.tests, but is now: org.apache.ant

Its required by:

org.eclipse.platform 4.40.0.v20260304-2033
org.eclipse.swtbot.eclipse.test.junit 4.3.0.202510091338
org.eclipse.ant.launching 1.4.1100.v20260304-1512
org.eclipse.ant.tests.ui 3.12.500.qualifier
org.eclipse.ant.ui 3.10.500.v20260304-1512
org.eclipse.jdt.apt.core 3.8.600.v20241001-0914
org.eclipse.test 3.6.500.v20260105-1638
org.eclipse.text.quicksearch 1.3.400.v20260117-1027
ZipEditor 1.1.9.202308271843

None of these re-export their dependency (visibility:=reexport) to org.apache.ant, so why is org.eclipse.jdt.debug.tests now able to use code from org.apache.ant? I can e.g. make this change:

@@ -51,7 +51,7 @@ import org.junit.rules.TestName;
  * Tests the Open from Clipboard action.
  */
 public class OpenFromClipboardTests {
-
+       org.apache.tools.ant.taskdefs.Ant a;
        /*
         * Copy of constants from OpenFromClipboardAction
         */

It will compile in Eclipse, but it should not. See OSGI specification:

https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module.requirebundle

The following directives can be used in the Require-Bundle header:

visibility - If the value is private (default), then all visible packages from the required bundles are not re-exported.
If the value is reexport then bundles that require this bundle will transitively have access to these required bundle's exported packages.
That is, if bundle A requires bundle B, and bundle B requires bundle C with visibility:=reexport
then bundle A will have access to all bundle C's exported packages as if bundle A had required bundle C.

[laeubi]

Regression from: #2218

"Too many" is nothing one can act on, you should proof at least one of them is not needed.

None of these re-export their dependency (visibility:=reexport) to org.apache.ant

Reexports are completely irrelevant here. This only controls if a bundle re-exports the packages but any requirement is required regardless of it is reexported or not.

so why is org.eclipse.jdt.debug.tests now able to use code from org.apache.ant?

That is a different question and you should first look at the classpath access rules. If they do not allow access to that package it might be a bug in JDT. But it could also be that the project explicitly allows/ignores forbidden references in wich case you would not be aware of it directly ... so it depends on many things and especially test projects are doing bad things often enough.

In this case:

• https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/0d00143b799e5a6aa13821204caa47d3da076e89/org.eclipse.jdt.debug.tests/.settings/org.eclipse.jdt.core.prefs#L50
• https://github.com/eclipse-jdt/eclipse.jdt.debug/blob/0d00143b799e5a6aa13821204caa47d3da076e89/org.eclipse.jdt.debug.tests/.settings/org.eclipse.jdt.core.prefs#L40

So the project explicitly opt-in to ignore any forbidden or discouraged reference.

It will compile in Eclipse, but it should not

Not everything that compiles will also run inside OSGi...

[iloveeclipse]

"Too many" is nothing one can act on, you should proof at least one of them is not needed.

See for example eclipse-jdt/eclipse.jdt.ui#2830 (comment)

Nothing in platform should have dependency to spotbugs and internal libraries existing in spotbugs bundle and not reexported.

Reexports are completely irrelevant here.

May be, but do you agree that org.eclipse.jdt.debug.tests can be both compiled and run without spotbugs and any library provided inside spotbugs bundle?

I'm not sure the fix #2218 that was supposed to fix compilation errors was done in the right way, so it would be good to go back to the roots and understand whether the issues it was supposed to fix (#2195 and #2115) could be fixed differently.

[laeubi]

Nothing in platform should have dependency to spotbugs and internal libraries existing in spotbugs bundle and not reexported.

As said this is a wrong assumption. reexports have nothing to do with classpath space.

May be, but do you agree that org.eclipse.jdt.debug.tests can be both compiled and run without spotbugs and any library provided inside spotbugs bundle?

It should as the imports are likely optional, but optional is only runtime-optional but mandatory at compilation time as there is no way for the compiler to handle an optional type.

I'm not sure the fix #2218 that was supposed to fix compilation errors was done in the right way, so it would be good to go back to the roots and understand whether the issues it was supposed to fix (#2195 and #2115) could be fixed differently.

Then again you should proof or elaborate why you think so and consider the mentioned difference between compile and runtime. I can't think of a way to guarantee consistent compilation without the full classpath and javac is simply failing we can just be lucky that ecj is sometimes a bit more lenient here.

[iloveeclipse]

E.g. org.eclipse.jdt.debug.tests had ~25 entries in the container before. It now has ~230.

This explains a lot why incremental builds are now so slow. I first assumed it's only because extra builds caused by "external" builders, but now with all them not doing anything after my patches I still see same slow builds.

"Too many" is nothing one can act on, you should proof at least one of them is not needed.

I believe enough proofs are given now?

1. No one should ever see spotbugs in SDK as dependency. Install Spotbugs into IDE (or import it from sources into workspace) and you will be able to add this code to org.eclipse.jdt.debug.tests without changing manifest:

		try {
			FindBugs2.main(new String[0]);
		} catch (Exception e) {
			e.printStackTrace();
		}

2. org.eclipse.jdt.debug.tests should not be able to compile code referencing to org.apache.ant

Boths are the same blocker issue, as now every incoming SDK patch may break the platform & anyone using platform coming M1 build.

The #2218 must be fixed or reverted ASAP!

@HannesWell, @merks : FYI.

[laeubi]

I believe enough proofs are given now?

Nope

The #2218 must be fixed or reverted ASAP!

I don't agree, it is working exactly as it is supposed to be. It is not the fault of PDE if projects are simply pull in the whole world.

org.eclipse.jdt.debug.tests should not be able to compile code referencing to org.apache.ant

This is wrong. As proven above the project explicitly disabled compiler warnings/errors in this regards so it can use anything without an error or warning.

Install Spotbugs into IDE (or import it from sources into workspace) and you will be able to add this code to org.eclipse.jdt.debug.tests without changing manifest

Only if you use your running Eclipse as a target platform (what is discouraged anyways) and if you disable the checks for discouraged / forbidden access.

[iloveeclipse]

I don't agree, it is working exactly as it is supposed to be. It is not the fault of PDE if projects are simply pull in the whole world.

#2218 breaks plugin development clearly.

@HannesWell, @merks : please step in as project lead and PMC members. I've failed to explain it, may be you can.

[laeubi]

#2218 breaks plugin development clearly.

Given that the Eclipse Platform SDK works without an issue this statement is wrong as well...

[iloveeclipse]

@laeubi : please can you explain, why org.eclipse.jdt.debug.tests can now compile code containing references to spotbugs classes without adding dependency to spotbugs (like import edu.umd.cs.findbugs.FindBugs2;)? Do you consider this as a feature that should be supported by PDE?