[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