Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] P2 Installation: PROP_INSTALL_FOLDER and PROP_CACHE + bonus issues

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



Back to the top