Embed the required StateFactory implementations

[laeubi]

Currently P2 has the BundleDescription in its API where the only implementation is in the discouraged osgi.compatibility fragment, but actually P2 does not really need a full implementation, it is just using that to parse manifest headers and generate metadata from it.

This embeds a stripped down version of the actual implementation in the p2.publisher.eclipse that allows to create implementation objects without rely on the compatibility fragment anymore.

This is currently work in progress and a way to track progress, the classes can most probably stripped down even more and currently depends on some equinox framework internals that probably should either be inline as well or an alternative should be chosen.

[github-actions]

Test Results

  375 files  +  125    375 suites  +125   45m 2s ⏱️ + 16m 42s
1 904 tests +    6  1 901 ✅ +    6  3 💤 ±0  0 ❌ ±0 
6 712 runs  +2 234  6 703 ✅ +2 231  9 💤 +3  0 ❌ ±0 

Results for commit 191df76. ± Comparison against base commit fcb6396.

♻️ This comment has been updated with latest results.

[laeubi]

Beside the zip packaging problem this seem to not break anything @merks do you want to give it a try with Ooomph?

@tjwatson what do you think? I know it is not nice to copy the code, but it seems unlikely P2 will ever be able to move away from the API interface and at least we can strip down everything to the bare minimum P2 is actually using here (e.g. it never uses a State anyways and would make PDE the only consumer of the compatibility fragment.

It seems without a state this always operates in "nonstrict mode" and we can even remove all code pathes that work on "strict" checks.

[merks]

It appears to cause no breakage for Oomph...

[laeubi]

One option would be if we move the fragment to P2 instead of copy one can simply link the sources here, see

• Move org.eclipse.osgi.compatibility.state from Equinox to P2 equinox#510

[tjwatson]

I'm not convinced making a copy here helps much with anything vs. using the APIs and implementation fragment as they are today.

[laeubi]

I'm not convinced making a copy here helps much with anything vs. using the APIs and implementation fragment as they are today.

The API will still be used (as we can't change this much) but the implementation (compatibility fragment) will not be required anymore as P2 don't really wants the "real" implementation, in fact is only uses that to parse the MANIFEST and provides that as a structured way to access the information.

So one can also reimplement that, but copy whats already there seems to be a faster approach.

[laeubi]

I have now pruned all unused code from the implementation using http://www.ucdetector.org/ and removed all references to the internal implementation of equinox.

[laeubi]

Moved to internal package and renamed some classes to make it more obvious what is done here.

[laeubi]

@merks @tjwatson if no further concerns I think we should merge this to get some more confidence everything works and possibly fix things if needed.

[merks]

FYI, I did check that this causes no compilation problem for Oomph so I think it's fine. I did not test behavior...

[HannesWell]

I'm not convinced making a copy here helps much with anything vs. using the APIs and implementation fragment as they are today.

The API will still be used (as we can't change this much) but the implementation (compatibility fragment) will not be required anymore as P2 don't really wants the "real" implementation, in fact is only uses that to parse the MANIFEST and provides that as a structured way to access the information.

Can't we migrate P2 to use the code from in the 'new' Equinox container, i.e. away from the old equinox resolver APIs?

[tjwatson]

LGTM

[laeubi]

Can't we migrate P2 to use the code from in the 'new' Equinox container, i.e. away from the old equinox resolver APIs?

Of course we can migrate to "something else" but I don't really see much benefit in that:

1. We would break the API here so special consideration is required to allow consumers to move away
2. The new API must be doing the same as the current API (or very similar) without any immediate benefit

So given PDE has moved away from this package we can decide to completely embed it into P2 instead of invent a new API and then we can even remove more things.