[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi guys,
We are developing an OSGi-based product and we are very interested in p2 as a provisioning system. We think it has a lot of potential, but what currently stops us from using it is
its tight coupling with the eclipse platform. That affects not only the binaries size but also logical dependencies to components which are not actually needed in our environment.
Our initial idea is to use p2 at runtime - we should be able to materialize a product defined in a p2 product file and then to provision the product by the same "agent" (self provisioning).
To serve that purpose we are implementing a tiny p2 client which provides basic functionality - access to p2 repository and interaction with our product (we will use pre-build repository).
What we propose is a simple API which provides that basic functionality and also to modify the currently existing p2 API to extend it. That would gives us the great opportunity not only
to use p2 for provisioning of non-eclipse product but also to embed that product into eclipse. We consider the latter as a big benefit with a little effort to decouple p2 functionality from
the rest of eclipse.
We strongly believe that there are many other parties who would be glad to use this last generation provisioning system, independent from the environment they run on.
Here is an example how this could be achieved for p2 engine API:
What is removed (as dependencies and functionality):
IStatus
IProgressMonitor
IProfileEvent
IProfileRegistry
ProfileScope
ISizingPhaseSet
What is modified to minimize dependencies:
public interface IEngine {
<the rest remains the same>
/**
* Executes a provisioning plan.
*
* @param plan The plan describing the changes to be made
* @param phaseSet The phases to run, or <code>null</code> to run default phases
* @return whether plan execution is successful or not
*/
public boolean perform(IProvisioningPlan plan, IPhaseSet phaseSet);
}
public interface IProfile extends IQueryable<IInstallableUnit> {
<the rest remains the same>
public IQueryResult<IInstallableUnit> available(IQuery<IInstallableUnit> query);
}
PhaseSetFactory
We're only interested in COLLECT, INSTALL and UNINSTALL phases, so the rest could be marked as not supported in the basic API
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.
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)
Looking forward to hear your comments on that topic,
Katya