I've been creating some Equinox+p2-enabled server platforms, and am
beginning some work on remote management of these environments.
One thing I've been looking at is the existing 'high-level' uses of p2
APIs...specifically ProvisioningHelper class (which is used by the
director app and the p2 console) and ProvisioningUtil (which is used by
the ui). Also, I've been looking at the installer's
InstallUpdateProductOperation, which performs operations (using the
IDirector, IProfileRegistry, etc) that are similar to some of the things
done by the ProvisioningHelper and ProvisioningUtil facades....but
So after looking at these...is it reasonable to say that these
could/should be consolidated? I know there are some deeper issues
raised by this (e.g. consistent/flexible initialization and
configuration of multiple osgi services behind these facades, setup
(exemplary or otherwise) of the services in various environments, etc).
Is there any desire/plan to concentrate on these issues for 3.5?
The reason this matters for me (working on p2-enabled remote
management), is that it would be nice to have a consistent local
high-level management/provisioning API (perhaps as a single osgi
service?) which could then be made available remotely (possibly as
remote OSGi services), published for network discovery, etc.