## Summary The OSGi resolver is the component that decides which bundles can run together. Eclipse (via Equinox and p2), Maven/Tycho builds and many other OSGi products depend on it. The current (open) implementation in use is the Apache Felix resolver, copied with modifications into Equinox. It works for most inputs, but it has known structural problems that no incremental patch has fixed in years. We are building a replacement prototype, `osgi-resolver-ng`, that is rule based and can always explain its result. We ask for funding to take it from a prototype to a production quality component on neutral ground, and to keep it maintained once it is used under the Eclipse License. ## Problem ### Resolve time can explode The Felix/Equinox resolver searches by permuting candidates and re-checking the whole class space after each failure. For real world states this can take minutes or never finish. Our measurements on a recorded 72 bundle Equinox state (Lucene and Mylyn, taken from a p2 installation, with one bundle that is genuinely unresolvable): | Resolver | Time | Outcome | |-----------|-------------|----------------------------------------------| | Prototype | about 0.2 s | 71 resolved, 1 reported with the reason | | Equinox | about 29 s | 71 resolved, but no exact reason for failing | | Felix | over 180 s | not finished | Synthetic scenarios show the same growth: with 16 consumers of two library versions Felix needs about 52 s and Equinox about 22 s, the prototype about 0.08 s. These are early numbers, they have to be re-checked once the implementation is complete. ### Failures cannot be explained A failed resolve says *that* something is missing, rarely *why*. Typical user reaction: "package `p` is missing, but bundle B exports `p`", and the real cause (version range, `uses` constraint, hidden by substitution, filtered by the resolve context) has to be found by hand. Even for a successful resolve nobody can ask why provider X was chosen over Y. For p2 based tooling, where an installation can fail at runtime although the install succeeded, this is a daily cost. ### Hard cases are poorly covered Substitution packages, `uses` constraints with several providers, fragments, `Require-Bundle` with re-exports and optional resources interact in ways that the specification only describes in scattered places. The two existing implementations also behave differently in places where the specification is silent. There is no shared, readable, executable description of the expected behavior. ### Governance is brittle The code lives twice (Felix and Equinox), the copies have diverged, and neither project is a natural place to decide who leads. Fixes have to be ported by hand, and nobody owns the whole. ## Approach - **Rules instead of blind permutation**: requirements usually forbid most combinations up front, so we prune with rules that each map to a section of the OSGi specification and search only what is left. - **Always explainable**: every result, successful or failed, carries the reasoning (why a candidate was chosen, why others were rejected), published through an optional diagnostics API that does not change the standard `org.osgi.service.resolver` contract. - **Behavior is documented by tests**: all scenarios are [Cucumber features](https://cucumber.io/docs/) that put resources in, call the resolver and inspect the wiring or the explanation. The same features run against the prototype, Felix and Equinox, so they serve as documentation and as a conformance comparison. - **No new dependencies**: Java 8 baseline, only the OSGi APIs, so it can be embedded where Felix or Equinox are today. ## Current State This is a prototype built as unpaid, exploratory work. It already has: - a broad scenario suite (more than 200 scenarios) derived from Felix, Equinox and the OSGi TCK, linked to public specification references, - an [explanation API (proposed for specification)](https://github.com/osgi/org.osgi.service.resolver/pull/45) with specific exception types, so tests can assert *why* a resolve failed, - first results on recorded real world states from Eclipse installations, - scenarios where we reason that the existing resolvers are wrong or specification is open, tagged for clarification with the OSGi specification group, - bugs and pitfalls found in the existing implementations while building it. It is not complete and not yet suited for production, and some hard areas remain open. We therefore treat the numbers above as promising, not as a promise. ## Proposed Work | Area | Content | |-----------------------|---------------------------------------------------------------------------------------------------| | Completeness | Remaining specification areas, hard search cases, robust handling of very large states | | Validation | Run against real Eclipse, p2 and Tycho states, compare results with Equinox and Felix | | Integration | Drop-in use as `Resolver` service, [a path for Equinox, p2 and Tycho to adopt it](https://github.com/osgi/org.osgi.service.resolver/pull/43) | | Explainability | Stable explanation API, readable messages, documentation for tool authors | | Specification feedback| Bring open questions and discovered differences to the OSGi specification group | | Stabilization reserve | Time budget for early adopter feedback and fast fixes (see below) | Exact scope, effort and schedule are to be agreed with the Planning Council. ## Sustainability A resolver that is wrong or slow in a case nobody tested blocks users completely, and they will return to the proven implementation if nobody reacts and continuing today frustration. Volunteer work alone cannot give the response times that this requires. Therefore the proposal includes: - a reserved budget for the first period after the first usable release and integration, for feedback and fixes of real world cases not covered yet, - every reported case becomes a permanent scenario, so the coverage grows with use, - a named maintainer with a defined response time during that period. ## Neutral Ground Neither Felix nor Equinox is a good long-term home, and deciding which one leads would block progress. We propose the [Eclipse OSGi Technology](https://github.com/eclipse-osgi-technology/) organization, which already hosts cross-cutting OSGi code. This is a suggestion, not a requirement, and the project is open to other neutral places. The result should be usable by Equinox, Felix and other consumers alike, without being a normative choice. ## Joining Forces The topic is also relevant for the [OSGi Working Group](https://www.osgi.org/about/), for example for the specification questions and for a shared conformance suite. We suggest that both working groups connect on this and consider joint funding. ## Why Now Eclipse builds and p2 installations keep growing, and resolve time and unexplainable failures are visible costs there. The prototype reduces the risk: the remaining investment is to finish and stabilize it, not to start. Without sponsorship the work continues at a volunteer pace, and an adoption path with guaranteed support is unlikely.