search

eclipse-equinox / p2

Eclipse Public License 2.0
15 stars 41 forks source link

Embed the required StateFactory implementations #455

Open laeubi opened 8 months ago

laeubi commented 8 months ago

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[bot] commented 8 months ago

Test Results

    9 files  ±0      9 suites  ±0   29m 7s :stopwatch: - 2m 19s 2 197 tests ±0  2 193 :white_check_mark: ±0   4 :zzz: ±0  0 :x: ±0  6 681 runs  ±0  6 670 :white_check_mark: ±0  11 :zzz: ±0  0 :x: ±0 

Results for commit f74d0516. ± Comparison against base commit 96d0fc51.

:recycle: This comment has been updated with latest results.

laeubi commented 8 months ago

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 commented 8 months ago

It appears to cause no breakage for Oomph...

laeubi commented 8 months ago

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

tjwatson commented 6 months ago

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

laeubi commented 6 months ago

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.