| Re: [p2-dev] P2 Isolation |
Hi,
Thank you for your interest in p2. Minimizing p2's footprint, improving its embed-ability and seeing it taken to new places are themes that we are all pretty interested in.
When we set out to do p2, it was not only meant to be used by Eclipse but as a general provisioning platform. However, as you have discovered, being the Eclipse guys, we reused the concepts that we were the most familiar with (extension registry, progress) because of expediency but also because our first delivery vehicle and target was the Eclipse SDK and a tight integration with the rest of the platform was necessary (ability to cancel, provide feedback to the user, etc).
Now that p2 has matured and people see the value of the platform, feedback and request for enhancements like these are really welcome and I'm really interested in understanding the background for those changes and see how they can be accommodated.
Now on to the specifics:
You seem to be concerned about the coupling with Eclipse. I can see where this would happen, but would appreciate if you could provide more details as to why you see some of these parts being more binding to eclipse than others. For example I gathered that you would not want to see the extension registry in your final solution, but is this because of its size? of its eclipse specific nature? What about status and progress monitoring?
>What is removed (as dependencies and functionality):
> IStatus
Status the eclipse way of returning errors in a structured way. Without it, how would you go about communicating back a more detailed error about what went wrong during the execution of the plan?
> IProgressMonitor
The progress monitoring has been added when we started working on the UI. Even though it "pollutes" the API, it turns out that it often a good way to be able to cancel a stuck download or also figure out where the system's at. Is this a matter of size?
What is interesting about those 2 previous items is that it resemble the shape of the first prototype I did :) The API eventually evolved into what it is today because of the requirements of serviceability and usability.
> IProfileEvent
The profile event was meant as a mechanism to decouple some of the p2 entities and also provide for external monitoring. You can probably do without it if you had no external piece that needed to monitor the progress of the engine. I would really like to understand what you have in mind here?
> IProfileRegistry
Are you removing this because you don't want to store the profiles at all, or because you know you will only work against one profile?
> ProfileScope
This will likely be trickier to remove since this is used by the repository managers to store their repositories. Should the issue be with the dependency on eclipse.preferences, I'm sure we can find a way to replace the equinox.preferences.
> ISizingPhaseSet
This interface, as well as most of the implementation of the phases can be moved out of the engine bundle.
[…]
> We have an idea about refactoring touchpoints as OSGi services which are standard instead of using eclipse specific extension points. We'd like to hear your opinion about that.
The actions and touchpoints are all encapsulated in the ActionManager and the TouchpointManager. The intent was for those to be "replaceable" and allow for actions and touchpoints to be contributed differently. I do not see any particular difficulty with this.
Again should the goal be to remove the usage of the extension registry, then you will need something similar in the metadata repository bundle.
>Modified in that way p2 engine depends only on (no other transitive dependencies):
> org.eclipse.equinox.p2.core
> org.eclipse.equinox.p2.metadata
> org.eclipse.equinox.p2.repository
>(Except OSGi framework, services and declarative services implementation)
In introduction you were mentioning how you were worried about size and coupling, what is your targeted size? With these set of changes you definitely cut the dependencies from the engine itself, but similar dependencies are brought in from p2.repository (for example it depends on jobs, ECF and equinox.common). Also are you thinking of writing your own touchpoints or reusing some of the ones we already provide?
What are the things you absolutely don't want to see and why?
Hope this helped and I'm really looking forward to hear your answers.
PaScaL