[p2-dev] P2 Installation: PROP_INSTALL_FOLDER and PROP_CACHE + bonus iss

[Manuel Woelker <mwoelker@xxxxxxxxxxxxxx>]

Hi p2-dev mailing-list!

I am currently working on a p2-based server deployment and update 
mechanism and ran into an issue I wanted to discuss. Overall my 
experience with p2 has been very positive, it is quite a powerful tool.

I was basically using the director (API, not the app) to perform an 
installation from a p2-update site. Everything seemed to be working 
well, at least judging from the return values. Trouble was my 
installation folder 
(PROP_INSTALL_FOLDER,"org.eclipse.equinox.p2.installFolder") was empty 
(or not even being created). I tried using the p2-installer, which 
worked fine. After quite some poking and prodding in the respective 
codebases, I finally found out that the way the p2-installer does it, is 
to set the PROP_CACHE ("org.eclipse.equinox.p2.cache") property. The P2 
director application does bascially the same the via using the 
"-bundlePool" command line argument.

So my question:
 1. Is setting the PROP_CACHE to the installation folder currently the 
correct way to install bundles into the directory?
 2. If yes, is this really a good way to do it? Using a cache as 
installation is not quite straightforward, and caused quite some 
confusion for me. Maybe it should be renamed or at least better documented.

On a slight tangent there are some other issues I ran into:
3. The majority of the p2 packages are internal/provisional atm. What 
are the plans for a publicly accesible API, from what I understand p2 
was envisioned as a general mechanism for dpendency and update 
management  and deployment.
4. Most of the p2 internals use a service locator pattern for finding 
the services. While this works well for eclipse installations and 
updates, it limits the use of p2 in other areas where several different 
deployments/installations/updates might be performed in parallel. 
Explicit declarations about which collaborators to use (i.e constructors 
taking IProfileRegistry, RepoManagers etc as arguments) would IMHO 
greatly improve reusability. For the existing use-cases a simple 
fallback to service-location could be realized.

I'd really like to hear you thoughs on these topics.

Cheers
- Manuel Woelker

--
Dipl.-Inform. Manuel Woelker
Innoopract Informationssysteme GmbH
mwoelker@xxxxxxxxxxxxxx
Tel: 0721 - 66 47 33 - 0
Fax: 0721 - 66 47 33 29


Innoopract Informationssysteme GmbH
Stephanienstrasse 20, 76133 Karlsruhe Germany
General Manager: Jochen Krause 
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883