search

eclipse-tycho / tycho

Tycho project repository (tycho)
https://tycho.eclipseprojects.io
Eclipse Public License 2.0
166 stars 189 forks source link

Get rid of P2 in tycho-core #2019

Open laeubi opened 1 year ago

laeubi commented 1 year ago

I recently evaluated the use of the OSGi Resource API and the OSGi Resolver API ad even connected those to "P2 World" in the bnd-test-mojo.

Given that these are standard OSGi APIs and are what actually is used under the hood in OSGi, we should start fading out P2 from tycho-core and move it finally to the p2-mojos all together, as P2 is no longer able to lead in that area:

See also:

akurtakov commented 1 year ago

Sounds like a plan. If more of p2 and/or its usages can be replaced by standard OSGi API that would be total win from maintenance POV.

laeubi commented 1 year ago

BND works without P2 and there is not much of a difference between both when it comes to the cores, just that BND uses some other metadata files, so I hope we can reuse many parts from that lib already.

mickaelistria commented 1 year ago

Sounds like a plan. If more of p2 and/or its usages can be replaced by standard OSGi API that would be total win from maintenance POV.

I second that.

tjwatson commented 1 year ago

I am not knowledgeable in how tycho uses p2 so my questions may not make any sense ...

Given that these are standard OSGi APIs and are what actually is used under the hood in OSGi, we should start fading out P2 from tycho-core and move it finally to the p2-mojos all together, as P2 is no longer able to lead in that area:

Does this have any impact on the ability for tycho to produce Eclipse features?

"Features" are a completely overloaded term so I don't want to confuse that with the Eclipse Platform features that everyone uses to install stuff into the Eclipse platform. I don't look for p2 to bolt on the OSGi "Features" stuff. It would be an interesting exercise, but one that would take a massive amount of work I think.

I'm also not sold on the OSGi "Features" specification. It is the second (or maybe third) attempt at such a standardization of deployment model for a group of resources. The first being osgi.subsystem.feature defined in the, now defunct, subsystems specification: https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.subsystem.html. And actually that was proceeded by a spec called "Initial Provisioning" that is now defunct also (https://docs.osgi.org/download/r6/osgi.cmpn-6.0.0.pdf)

I would exercise caution to move to a specification that has only one implementations and user so far.

laeubi commented 1 year ago

I am not knowledgeable in how tycho uses p2 so my questions may not make any sense ...

Questions are always welcome as sometimes a good question is showing new perspectives to a problem that seems solved, on a high level Tycho uses P2 to answer the question does X require Y given a set of requirements and capabilities.

Does this have any impact on the ability for tycho to produce Eclipse features?

Tycho actually never "produce" a feature, it just resolves some variables against the current build and package that into a jar file, so I think Tycho will always support that, but probably will also be able to handle the new OSGi-Json-Features.

"Features" are a completely overloaded term so I don't want to confuse that with the Eclipse Platform features that everyone uses to install stuff into the Eclipse platform. I don't look for p2 to bolt on the OSGi "Features" stuff. It would be an interesting exercise, but one that would take a massive amount of work I think.

Yes the term is a bit overloaded, but "Eclipse Feature" is just a subset of "OSGi Feature" and actually Tycho can already transform a "P2 Feature" into an "OSGi Resource", so they can interact (on a certain level), thats why I already have opened:

because "PDE Feature" is again a bit different even though currently we can transfor "PDE Feature" > "P2 Feature" :-)

I would exercise caution to move to a specification that has only one implementations and user so far.

You mean like "PDE features" :-D Just to clarify, it is not to replace one for the other, but Tycho should use a model that can express both and currently is sadly bound to the P2-model (with just "one implementations and user") and it seems P2 is not capable of catching up with enhancing the model in a way to express more, while I think the OSGi Resource API does very well!

With recent added support for BND-Testing in Tycho I was able to transform P2 > Resources in a way understood by the Resolver so that is for me a very good indication that the Resource model is a super-set of the P2 Model.

tjwatson commented 1 year ago

OK, it sounds to me that the usage of p2 by tycho is an implementation detail then. If so, then dropping the usage of it may simplify some things for you.

it seems P2 is not capable of catching up with enhancing the model in a way to express more, while I think the OSGi Resource API does very well

I am a fan of the OSGi Resource API and the Resolver API. After all, I rewrote the core Equinox Framework to be based on this API instead of trying to keep the old Equinox resolver model. What I'm not convinced of is making p2 implement OSGi Features, but that is another topic. Since I've never really spent much time implementing nor designing p2, it is outside of my zone of interest.

The OSGi Features specification makes reference to the theoretical feature "launcher", but mentions no way of finding, creating or feeding a launcher some set of OSGi Features to manage and install. There is no mention of how to update features. It is only a set of meta-data that then has to have some proprietary way of realizing the feature content into the runtime. It doesn't even mention really anything about resolving the feature. It isn't even clear it mandates the use of the Repository or Resolver service, let alone the Resource API of OSGi.

All of that is to say, I am not clear on who will use the OSGi feature meta-data when tycho adds support for it.

laeubi commented 1 year ago

I am a fan of the OSGi Resource API and the Resolver API. After all, I rewrote the core Equinox Framework to be based on this API instead of trying to keep the old Equinox resolver model.

That's especially something I hope to archive as well so we actually share the same technology for those purpose, next step would be to use that in PDE as well.

The OSGi Features specification makes reference to the theoretical feature "launcher", but mentions no way of finding, creating or feeding a launcher some set of OSGi Features to manage and install.

Yeah that's missing, I hope it gets some spin and is inspired by Karaf, that already has a FeatureService to manage features and resolves them and all kind of cool stuff!

All of that is to say, I am not clear on who will use the OSGi feature meta-data when tycho adds support for it.

For Tycho a feature is just a file in a special format that can be packed and results in requirements and capabilities, so the actual format does not mater much (also P2 is actually not bound to a storage-format).

But features (as a set of requirements) are also used to build products for example or launch things, build sites and so on, so if one better likes to write that up in the (official) JSON format and this provides more power, why not.

mickaelistria commented 1 year ago

Slightly related, I tried once to get rid of some older APIs in p2 to use OSGi ones instead: https://git.eclipse.org/r/c/equinox/rt.equinox.p2/+/175591 . I gave up as it was too long and difficult compared to the value it could have brought to the cases I support; but maybe it's more relevant and easier now for others...