Do not follow generic requirements when computing the classpath by laeubi · Pull Request #2256 · eclipse-pde/eclipse.pde

laeubi · 2026-03-12T12:43:40Z

OSGi uses a generic Provide-Capability/Require-Capability model that
allows to declare requirements beyond the classic Import-Package and
Require-Bunlde. A common example is a bundle that provides a DS
component and needs an extender to actually construct the component and
inject the services. Another is a logging API that needs a provider.

These are especially needed because in such scenario a provider/consumer
do not know each other and should not depend directly (only loosely
coupled). Currently such providers are still pulled in even though they
are not contribute to the compilation classpath as they are completely
invisible at runtime - there is a wiring but no classloader access
granted.

This now adds a new option to the DependencyManager to exclude generic
requirements from the computation of the dependency closure and the
RequiredPluginsClasspathContainer is using that option to avoid follow
such generic wiring contracts.

Includes the testcase from PR #2254

github-actions · 2026-03-12T13:11:22Z

Test Results

147 files ±0 147 suites ±0 36m 9s ⏱️ - 2m 50s
3 495 tests +2 3 441 ✅ +2 54 💤 ±0 0 ❌ ±0
9 306 runs +3 9 176 ✅ +3 130 💤 ±0 0 ❌ ±0

Results for commit bf4ca14. ± Comparison against base commit 693ecb5.

♻️ This comment has been updated with latest results.

ptziegler · 2026-03-12T13:16:36Z

+		TestUtils.waitForJobs("ClasspathResolutionTest.testRequiredPluginsViaCapabilityForFragment", 200, 30_000);
+
+		List<String> requiredPluginContainers = getRequiredPluginContainerEntries(projectConsumer);
+		assertThat(requiredPluginContainers).contains("A1_0_0");


This check seems to be causing problems now, but the important check is the one below. Should it simply be removed?

Strange it runs locally if I execute it alone but fails when running the full test-suite... I will take a look.. maybe simply rename the project would already help.

Renaming does not change anything... but it reproducible succeeds when executed alone and fails when executed with all tests...

I found that the "loadTargetPlatform" of the other test somehow broke the test. It then finds the host but the host is not resolved. So it seems that somehow even though tried it does not.

Looking at the test itself it more is about system packages from target platorms so I will no try to extract your testcase in a separate class instead...

@ptziegler I have now extracted this into "real" projects making it easier to investigate/debug.

The problem is that the setup seem to have some (intermediate) problem and the target state complains:

java.lang.AssertionError: Expecting empty but was: [Constraints from the fragment conflict with the host: Require-Capability: some.test.capability] at org.eclipse.pde.core.tests.internal.classpath.ClasspathResolutionTest2.testRequiredPluginsViaCapabilityForFragment(ClasspathResolutionTest2.java:802) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.eclipse.pde.ui.tests.runtime.TestUtils$1.evaluate(TestUtils.java:267) at org.eclipse.pde.ui.tests.runtime.TestUtils$1.evaluate(TestUtils.java:267)

interestingly one can make it work by making some changes to the EE and then switch back.

This happens because the ordering of resolve is important here... so importing the host first and then the *fragment triggers the error.

I'll check if we can avoid that... to me it seems if one asks for an incremental resolve of a fragment the host must also be part of that set...

HannesWell

This totally makes sense to me and it should prevent problematic cycles (at least those that don't lead to cycle-errors on a workspace project level too).

However I have alternative suggestions for the specific implementation.

HannesWell · 2026-03-13T00:28:34Z

 		Set<BundleDescription> closure = DependencyManager.findRequirementsClosure(added,
-				INCLUDE_OPTIONAL_DEPENDENCIES);
+				INCLUDE_OPTIONAL_DEPENDENCIES, EXCLUDE_REQUIRED_CAPABILITY);


In fact we already have a facility in PDE that computes what you want to obtain here:

Suggested change

Set<BundleDescription> closure = DependencyManager.findRequirementsClosure(added,

INCLUDE_OPTIONAL_DEPENDENCIES);

INCLUDE_OPTIONAL_DEPENDENCIES, EXCLUDE_REQUIRED_CAPABILITY);

Set<BundleDescription> closure = BuildDependencyCollector.collectBuildRelevantDependencies(added)

It's currently an own implementation, but I have just opened a PR that migrates it to use the DependencyManager (after the change was just on my computer for a long time):

Replace BuildDependencyCollector by DependencyManager #2257

In fact you should already be able to use that code now, even without my PR.
Then you don't have to modify DependencyManager at all and introduce a new constant for it.

And then further down below the system bundle does not have to be filtered anymore.

HannesWell · 2026-03-13T00:33:17Z

+				BundleCapability capability = wire.getCapability();
+				if (excludeGenericRequiredCapability) {
+					String namespace = capability.getNamespace();
+					if (!BundleNamespace.BUNDLE_NAMESPACE.equals(namespace)
+							&& !PackageNamespace.PACKAGE_NAMESPACE.equals(namespace)
+							&& !HostNamespace.HOST_NAMESPACE.equals(namespace)
+							&& !ExecutionEnvironmentNamespace.EXECUTION_ENVIRONMENT_NAMESPACE.equals(namespace)) {
+						// If it is not one of the framework namespaces it is a
+						// generic one see https://docs.osgi.org/specification/osgi.core/8.0.0/framework.namespaces.html
+						continue;
+					}
+				}
+				BundleRevision provider = capability.getRevision();


For that particular change I have a counter proposal in:

Replace BuildDependencyCollector by DependencyManager #2257

This doesn't require a new constant within the DependencyManager, which is also quite specific to PDE respectively the build time requirement. In general I would like to keep DependencyManager generic in the hope that it could be up-streamed to OSGi in some form at some day.

Plus I'm not sure if it's necessary to follow EE-namespace wires. See also

Replace BuildDependencyCollector by DependencyManager #2257 (comment)

OSGi uses a generic Provide-Capability/Require-Capability model that allows to declare requirements beyond the classic Import-Package and Require-Bunlde. A common example is a bundle that provides a DS component and needs an extender to actually construct the component and inject the services. Another is a logging API that needs a provider. These are especially needed because in such scenario a provider/consumer do not know each other and should not depend directly (only loosely coupled). Currently such providers are still pulled in even though they are not contribute to the compilation classpath as they are completely invisible at runtime - there is a wiring but no classloader access granted. This now only follows build time requirements to avoid the situation.

laeubi force-pushed the pr-2254-cyclic branch from 3d31f48 to 3a164bf Compare March 12, 2026 12:43

laeubi mentioned this pull request Mar 12, 2026

Add reproducer for cyclic bundle dependencies caused by #2218 #2254

Closed

ptziegler reviewed Mar 12, 2026

View reviewed changes

HannesWell reviewed Mar 13, 2026

View reviewed changes

Add reproducer for cyclic bundle dependencies caused by eclipse-pde#2218

c02aadd

laeubi force-pushed the pr-2254-cyclic branch from 282c010 to ecb0fe1 Compare March 17, 2026 10:14

laeubi force-pushed the pr-2254-cyclic branch from ecb0fe1 to bf4ca14 Compare March 17, 2026 10:17

HannesWell approved these changes Mar 17, 2026

View reviewed changes

laeubi merged commit 79b22ee into eclipse-pde:master Mar 17, 2026
19 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Do not follow generic requirements when computing the classpath#2256

Do not follow generic requirements when computing the classpath#2256
laeubi merged 2 commits intoeclipse-pde:masterfrom
laeubi:pr-2254-cyclic

laeubi commented Mar 12, 2026

Uh oh!

github-actions bot commented Mar 12, 2026 •

edited

Loading

Uh oh!

ptziegler Mar 12, 2026

Uh oh!

laeubi Mar 12, 2026

Uh oh!

laeubi Mar 12, 2026

Uh oh!

laeubi Mar 12, 2026

Uh oh!

laeubi Mar 13, 2026

Uh oh!

HannesWell left a comment

Uh oh!

HannesWell Mar 13, 2026 •

edited

Loading

Uh oh!

HannesWell Mar 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

laeubi commented Mar 12, 2026

Uh oh!

github-actions bot commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

ptziegler Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

laeubi Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

laeubi Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

laeubi Mar 12, 2026

Choose a reason for hiding this comment

Uh oh!

laeubi Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

HannesWell left a comment

Choose a reason for hiding this comment

Uh oh!

HannesWell Mar 13, 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!

HannesWell Mar 13, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions bot commented Mar 12, 2026 •

edited

Loading

HannesWell Mar 13, 2026 •

edited

Loading