[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] P2 Installation: PROP_INSTALL_FOLDER and PROP_CACHE + bonus issues
|
Hi Manuel,
This bug [at least] is relevant to your questions
[director] support running director against different agent location
https://bugs.eclipse.org/bugs/show_bug.cgi?id=248755
Scott
Manuel Woelker wrote:
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