[
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