p2 can install a bundle family that OSGi cannot resolve when a third-party constraint pins one member

[hspdf]

Summary

When several bundles form a family that imports each other's packages with strict micro-version ranges, and one member is held back by a version constraint from an unrelated installed component, p2 will happily upgrade the remaining members. The resulting profile is valid by p2's rules but cannot be resolved by OSGi, and the installation is only discovered to be broken on the next start.

Concrete case

Eclipse IDE for Enterprise Java and Web Developers, buildId 4.40.0.20260604-0652, Java 25.0.3, Linux GTK x86_64. A routine "Check for Updates" on 2026-09-01 08:38 UTC installed 78 jars (m2e 2.11.0, m2e.logback 2.7.300, m2e.pde 2.3.800, 19 EMF features, Checkstyle 13.9.0, plus bnd 7.4.0, lsp4e, tm4e and others). Among them four of the five ASM bundles:

org.objectweb.asm                9.9.1  +  9.10.1
org.objectweb.asm.commons        9.9.1            <- not upgraded
org.objectweb.asm.tree           9.9.1  +  9.10.1
org.objectweb.asm.tree.analysis           9.10.1
org.objectweb.asm.util                    9.10.1

Afterwards the IDE would not start:

java.lang.RuntimeException: Application "org.eclipse.ui.ide.workbench"
could not be found in the registry.

Why the resulting state cannot resolve

The Orbit ASM bundles import each other with strict micro ranges:

org.objectweb.asm.commons 9.9.1   imports org.objectweb.asm [9.9.1,9.10)
org.objectweb.asm.util    9.10.1  imports org.objectweb.asm [9.10.1,9.11)

org.apache.aries.spifly.dynamic.bundle imports org.objectweb.asm, org.objectweb.asm.commons and org.objectweb.asm.util, each [9.6,10). With only asm.commons 9.9.1 and asm.util 9.10.1 available, spifly is exposed to two conflicting wirings of the org.objectweb.asm package and fails on a uses constraint. On Eclipse 4.36+ that cascades into the workbench, because org.eclipse.jface and org.eclipse.ui mandatorily require the SVG capability provided by org.eclipse.swt.svg → jsvg → SPI-Fly → ASM. See eclipse-platform/eclipse.platform.ui#4328 for that part.

Why p2 chose this

From the profile snapshot taken before the update, exactly two IUs consume asm.commons:

org.apache.aries.spifly.dynamic.bundle 1.3.7  ->  [9.6.0,10.0.0)   open
org.jacoco.core 0.8.14                        ->  [9.9.0,9.10.0)   pinned

EclEmma's JaCoCo pins asm.commons to 9.9.x. The other four ASM bundles are only referenced through open ranges, so p2's "prefer newest" took them to 9.10.1 and left asm.commons behind. Every individual choice is legal; the combination is not installable.

Note this is not caused by an incomplete repository. org.objectweb.asm.commons 9.10.1 exists in Orbit Aggregation 2026-09 and installs fine — I later added that site and installed it explicitly with p2.director -installIU. Even with the complete family visible, p2 does not add it on its own, because 9.9.1 already satisfies spifly's open range. A complete repository produces the identical split.

What I would like to ask for

Not full uses-constraint modelling in the solver. I understand that is a large investment (@akurtakov made the same point in eclipse-platform/eclipse.platform.ui#4328).

Something narrower would already have prevented this: validate the computed provisioning plan against the OSGi resolver before applying it. p2 has every manifest in hand at that point. Running Equinox's resolver over the prospective bundle set and refusing (or at least warning) when it does not resolve would turn a silently broken installation into an error message while the old, working configuration is still in place. That is a validation pass rather than a change to the SAT solver.

If that is still too costly, even detecting the narrow pattern would help: two versions of the same exported package, both reachable from a single requirer whose import ranges span both.

Related

This failure shape has come up repeatedly:

• OSGi resolution failure on macOS due to mixed org.objectweb.asm bundle versions (9.9.1 + 9.10.1) eclipse-platform/eclipse.platform#2833 — same ASM version table
• Cannot start I20260530-1800 after installing platformUiTools.p2f eclipse-platform/eclipse.platform.ui#4038 — uses violation in spifly
• Broken Eclipse installation with Oomph after update eclipse-oomph/oomph#203 — same morning, same update wave
• ASM does not specify upper bounds on import ranges eclipse-orbit/orbit-simrel#58 — the ASM manifest ranges

@merks noted in oomph#203 that bouncycastle produces the same shape, so it is not ASM-specific. He also suggested in #4328 that singleton:=true on the ASM bundles would have forced a coherent outcome. That is true (JaCoCo would have capped the whole family at 9.9.1), but it would also forbid legitimate side-by-side installs, so it seems more like an Orbit-side trade-off than a general fix.

[merks]

For analysis it's convenient that a profile is a p2 metadata repository, so one can explore it:

As such, one can use the CBI p2 aggregator to analyze it.

Here we see the full combination of asm bundle versions that are installed. It's the Strict Requirements view so it shows what these bundles provide (provided capabilities) and under each of those what other bundles require that capability along with the version bounds of that requirement. (It only shows provided capabilities that are required elsewhere, not all provided capabilities).

We see spifly selected in the view and from those we see that its ranges constraints are [9.6.0,10.0.0} on both asm.commons and asm.until. So it's apparently quite satisfied with a combination of minor version asm.commons (9.9.x) and asm.util (9.10.x). Despite what one might assume about those package/bundle names, these are not packages used across other asm bundle but mostly only outward facing.

Note that jacoco does not depend on asm.util, so it does not constrain asm.util's version to 9.9.x. But it does use asm.commons and constrains that version to 9.9.x. Hence the dysfunctional combination of those two bundle; dysfunctional because asm.util 9.10.x requires specifically asm 9.10.x and is not satisfied by asm 9.9.x which is actually present.

I'm not sure how we could impose constraints to keep the combination consistent. I'm pretty sure that two full sets of the versions would be fully functional (i.e., they don't need to be singletons). If jacoco required asm.util and constrained it to 9.9.x like it does for its other package requirements, I believe that would solve the problem. But maybe that's an unreasonable ask because jacoco isn't just used in Eclipse installations (I think).

Looking further, EclEmma has very narrow constraints on jacoco:

If EclEmma specified a very narrow package import (or bundle requirement) on asm.util that would also solve the problem (I believe):

I'm not sure what other ways we might constrain the solution such that a 9.9.x of asm.commons and 9.9.x of asm.util are both available. It seems best done by jacoco or EclEmma given those are the source of the strict bounds that require older version of asm.commons.

@Godin @iloveeclipse

Would it be reasonable to add a requirement to jacoco (probably not), or EclEmma (probably makes sense because that's what drives the problem in an Eclipse installation) that would force a matching 9.9.x version of asm.util to be available wherever EclEmma is installed?

This is a really serious problem that tends to recur ever time here is an ASM update. With frequent Java releases (new class file formats) that tends to be very often; Java 28 betas are already floating around, so I expect the hassle again very soon.

[merks]

If I force the 9.9.x asm.util to be (remain) installed, the IDE does start with a (this) combination of asm versions.

With the newer m2e also installed:

[iloveeclipse]

Would it be reasonable to add a requirement to jacoco (probably not), or EclEmma (probably makes sense because that's what drives the problem in an Eclipse installation) that would force a matching 9.9.x version of asm.util to be available wherever EclEmma is installed?

Yes, I can't imagine how that would be a problem, ASM as a whole is a very small and has no dependencies.

Ideally ASM would continue to provide https://mvnrepository.com/artifact/org.ow2.asm/asm-all additionally to 6 smaller subsets of ASM, I'm not sure why the team stopped to release this.

[merks]

Probably in terms of maven dependencies, the asm-bom serves a similar purpose:

https://repo.maven.apache.org/maven2/org/ow2/asm/asm-bom/

But that doesn't really help us in this (OSGi/p2) context.

When the next round of asm updates come, I can help out with this idea so we can also test that it works in advance to avoid another round of this problem. Though maybe it's good to start sooner with the current 9.10.x version ahead of a 9.11.x version existing?

[iloveeclipse]

Though maybe it's good to start sooner with the current 9.10.x version ahead of a 9.11.x version existing?

If you have some free cycles, sure :-). Managing different sets of ASM dependencies in different bundles (Xtext, PDE, Jacoco) is/was a constant PITA.

[laeubi]

When several bundles form a family that imports each other's packages with strict micro-version ranges

I just wanted to note that this is usually bad habit (if not wrong) from OSGi point of view and nothing good comes from it, see OSGi Semantic Versioning - Semantic Versions.

A difference in the micro part does not signal any backward compatibility issues. The micro number is used to fix bugs that do not affect either consumers or providers of the API.

So even though it is possible to import with a micro version, one should usually only use the minor in the lower bounds!

So if one follow the rules and has proper version range then usually P2 do a good job as well - such problems more arise with packages that look independent (but are not) and then OSGi can not do a better choice. If you really face a use-constraint violation and not an unresolved requirement error this usually means that at least also the metadata is flawed and missing a proper use-constraint definition.

[merks]

The asm family is constrained by minor version ranges so the initial statement of the issue is a little off base. Also jacoco constrains asm with minor version ranges. I think the OSGi metadata is also correct and complete. It’s just that at install time, nothing notices there is a bundle that necessarily will be bound to two different versions of asm.

It probably doesn’t make sense to repeat what I already explained. Probably it’s all just too much information already.

[laeubi]

I'll try to take a look at the p2 part if there is anything (reasonable) we can do. For this it would be good if there is a set of repositories to use and some root IUs to reproduce the problem without having to perform a full eclipse install.

We see spifly selected in the view and from those we see that its ranges constraints are [9.6.0,10.0.0} on both asm.commons and asm.until. So it's apparently quite satisfied with a combination of minor version asm.commons (9.9.x) and asm.util (9.10.x). Despite what one might assume about those package/bundle names, these are not packages used across other asm bundle but mostly only outward facing.

Note that jacoco does not depend on asm.util, so it does not constrain asm.util's version to 9.9.x. But it does use asm.commons and constrains that version to 9.9.x. Hence the dysfunctional combination of those two bundle; dysfunctional because asm.util 9.10.x requires specifically asm 9.10.x and is not satisfied by asm 9.9.x which is actually present.

So can we say it requires spifly+jacoco (any specific version?) + asm 9.9.x and asm.util 9.10.x?

[laeubi]

I'm not sure what other ways we might constrain the solution such that a 9.9.x of asm.commons and 9.9.x of asm.util are both available.

Just a general note if I read this correctly

org.apache.aries.spifly.dynamic.bundle imports org.objectweb.asm, org.objectweb.asm.commons and org.objectweb.asm.util, each [9.6,10). With only asm.commons 9.9.1 and asm.util 9.10.1 available, spifly is exposed to two conflicting wirings of the org.objectweb.asm package and fails on a uses constraint.

there seem something fishy in the asm meta-data ... the resolver should simply not resolve such combination of asm has proper use-constrains on its exports!

[laeubi]

I have now analyzed both asm version from maven central and they look sane in regards to their exports/imports and use-constrains. So I think the use-constraint error here is a little misleading from the resolver: There are actually no alternatives to wire this correctly and the resolver bails out with an error that should be more specifically mentioning this case - but this is not really possible with todays code structure.

So what should fix the install is to install the additional missing dependencies and P2 should be enhanced to detect at least this situation here and install both full sets of asm where currently it considers the both package imports to be independent - I'll take a look.

[laeubi]

@hspdf any chance you can share your p2 profile so we can see what exactly was updated?
I made some experiments now and can't fore p2 during an update to install a new asm version - only if I add something that explicitly requires a never asm version. Even though it of course should work in both cases I want to understand how asm 9.10 is pulled in at all during an update where everyone seem to be happy with 9.9 ...

[laeubi]

I now created a reproducing test case here:

• [draft] P2 Use-Constraint support #1122

the "trick" seems to be that I emulated the case of org.eclipse.jdt.bcoview that has Require-Bundle: org.objectweb.asm.util; bundle-version="9.4.0" what has no upper bound, so this always leans towards the most recent asm.util (what pulls more recent asm bundles) but never requires asm.common in its dependency chain. This then leads to the situation here that almost all never bundles are installed, p2 tends to not modify the spifly (because it is still seems satisfied).

The oddity here is why it seem to uninstall the asm.util 9.9.1 version (likely because it thinks no one need it anymore) - if it would have leaved it untouched the state would likely be resolvable here!

[hspdf]

@laeubi That matches the real-world profile exactly, org.eclipse.jdt.bcoview is
the same lever here. Attaching the profiles anyway (p2-profile-1119.zip): the last
known-good snapshot from 2026-08-19 and the one written directly after the
breaking update on 2026-09-01, in case the real data is useful next to the
synthetic case.

The oddity here is why it seem to uninstall the asm.util 9.9.1 version (likely
because it thinks no one need it anymore)

Your guess is right, and the before/after profile shows the contrast cleanly:

asm                9.9.1  ->  9.9.1 + 9.10.1     kept its 9.9.1 copy
asm.commons        9.9.1  ->  9.9.1              never moved
asm.tree           9.9.1  ->  9.9.1 + 9.10.1     kept its 9.9.1 copy
asm.util           9.9.1  ->  9.10.1             9.9.1 dropped
asm.tree.analysis  9.9.1  ->  9.10.1             9.9.1 dropped

The three that kept a 9.9.1 copy are exactly the three JaCoCo pins:

org.jacoco.core 0.8.14  -> asm          [9.9.0,9.10.0)
org.jacoco.core 0.8.14  -> asm.commons  [9.9.0,9.10.0)
org.jacoco.core 0.8.14  -> asm.tree     [9.9.0,9.10.0)

The two that lost it have only unbounded consumers:

org.apache.aries.spifly.dynamic.bundle 1.3.7  -> asm.util          [9.6.0,10.0.0)
org.eclipse.jdt.bcoview 1.3.0                 -> asm.util          9.4.0
org.eclipse.jdt.bcoview 1.3.0                 -> asm.tree.analysis 9.4.0

So p2 is being consistent: it keeps a superseded version only while something
still requires it. Once 9.10.1 satisfied both consumers of asm.util, nothing
needed 9.9.1 any more.

if it would have leaved it untouched the state would likely be resolvable here!

Confirmed empirically, that is exactly the repair I applied before opening this
issue. I rewrote bundles.info so all five ASM bundles were 9.9.1 (every jar was
still in the bundle pool), started with -clean, and the IDE came up:
org.apache.aries.spifly.BaseActivator logged its registered providers, which is
the step that had been failing, and no new log was written to configuration/.
@merks reported the same result earlier in this thread by forcing asm.util 9.9.x.

So keeping the superseded version of a bundle while a sibling in the same
tightly-coupled set cannot move would have been enough in this case, without
needing full uses-constraint modelling.

p2-profile-1119.zip

[merks]

if it would have leaved it untouched the state would likely be resolvable here!

This is the nature of the "fix" in the EclEmma,i.e., the PR bounds also asm.common in the range that jacoco bounds all the other asm bundles.

The workflow is still waiting for someone to push a button:

eclipse-eclemma/eclemma#155