Move org.eclipse.osgi.compatibility.state from Equinox to P2

[laeubi]

It seems the org.eclipse.osgi.compatibility.state is actually only used at the following places:

1. PDE
2. P2
3. FrameworkAdmin (what is already part of P2)

I therefore wonder if it would be feasible to move it to the P2 repository like the FrameworkAdmin that also is only used by P2+PDE.

[merks]

I see these direct dependencies:

But it's a hosted fragment so it can't just be moved can it?

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %Bundle-Name
Bundle-SymbolicName: org.eclipse.osgi.compatibility.state
Bundle-Version: 1.2.1000.qualifier
ExtensionBundle-Activator: org.eclipse.osgi.compatibility.state.Activator
Fragment-Host: org.eclipse.osgi;bundle-version="3.12.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.8
Bundle-Vendor: %Bundle-Vendor
Automatic-Module-Name: org.eclipse.osgi.compatibility.state

[laeubi]

It will still stay a fragment of org.eclipse.osgi only the project should move from Equinox > P2 repository, nothing else should change (e.g. name or host).

[tjwatson]

I don't understand the motivation to move the implementation away from the API here in org.eclipse.osgi. Especially to the p2 repository where I would prefer it to stop using the old implementation.

[laeubi]

I don't understand the motivation to move the implementation away from the API here in org.eclipse.osgi

The idea is that actually once no one should ever use that API (what we probably can't remove) so hosting an implementation for it is quite useless / confusing (it currently uses reflection to actually make it available already because of this).

Especially to the p2 repository where I would prefer it to stop using the old implementation

As there is no new implementation I don't see how P2 ever will move away from it without major efforts (its part of its a major public API use almost everywhere either directly or indirectly...) reimplementing the API or use compatibility fragment forever.

At P2 it has two consumers:

1. FrameworkAdmin what is already part of P2
2. BundlesAction where it actually only wants to represent a BundleManifest in an object oriented way

so basically as Equinox has no use of that API anymore and we won't suggest anyone to use that API anyways for new design, it could be "downgraded" to only contain the interfaces but not the implementation. Technically one might even can move the interfaces into the compatibility fragment as well.

[tjwatson]

The idea is that actually once no one should ever use that API (what we probably can't remove) so hosting an implementation for it is quite useless / confusing (it currently uses reflection to actually make it available already because of this).

Equinox provides many things that it itself does not use. For example, org.eclipse.equinox.bidi, org.eclipse.equinox.registry, org.eclipse.equinox.preferences ... I don't see that as a reason to move source code around with no benefit.

I don't know what becomes better when we move the implementation away from the API, and moving the API requires much more thought. I also don't think moving the API should involve a compatibility fragment of org.eclipse.osgi. We should simply move the API and the implementation into its own single, standalone (non-fragment) bundle. That in itself would be a breaking change for anyone (gulp) using require-bundle on org.eclipse.osgi to get the org.eclipse.osgi.service.resolver API. That is the reason I didn't move the API out along with the implementation in the first place when we moved the framework to use the OSGi resolver/resource specification.