[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] platform:/base URL resolution and shared installs inheriting bundle-pool extensions in Eclipse 3.5/3.6
- From: Nalini Ganapati <nalinig@xxxxxxxxxx>
- Date: Thu, 10 Dec 2009 11:09:02 -0800
- Delivered-to: email@example.com
Would like to add, for the mocked up
eclipse, the references to plugins/ in bundles.info were replaced by file:C:/eclipse-extensions/plugins/
And for the second issue of the shared
install not inheriting the bundle-pool extensions, I found the answer to
that. After bringing up the mocked up eclipse from a normal install, the
newer p2 profiles seem to have lost the bundle-pool extension as well.
I am trying to head off issues even before we have our installer functional,
thus the mocked up eclipse. And if anyone can see issues with the mocked
up scenario, please point them out too.
Thanks for any help,
||P2 developer discussions <p2-dev@xxxxxxxxxxx>
||12/10/2009 10:39 AM
||[p2-dev] platform:/base URL resolution
and shared installs inheriting bundle-pool extensions in Eclipse 3.5/3.6
platform:/base should be set to the
directory containing the eclipse executable. But, in reality, from our
past experience with Eclipse 3.4, this was resolved based on other locations
like where the org.eclipse.equinox.launcher plugins were located. Our installer
installs all eclipse features/plugins including the org.eclipse.equinox.launcher
plugins in a directory different from the one containing the eclipse executable.
For our Eclipse 3.5 and 3.6 based products, the directory containing the
plugins will be referred to by org.eclipse.equinox.p2.cache.extension property
in the p2 profile - bundle pool extension - and the directory containing
the eclipse executable and the configuration will be the bundle pool. I
performed a mock-up of this with an unzipped eclipse 3.6 M3. Basically,
after unzipping to say C:/eclipse, I moved the plugins/, features/ and
artifacts.xml to another folder, say C:/eclipse-extension and fixed up
references in config.ini. eclipse.ini, p2 profiles(fixed up the org.eclipse.equinox.p2.installFolder,
org.eclipse.equinox.p2.cache and org.eclipse.equinox,p2.cache.extensions
properties) . I also modified platform.xml site referring to platform:/base
to C:/eclipse-extension and added another empty site for platform:/base.
I am able to bring up a functional eclipse, can install new software using
either dropins or the p2 installer. But, if we look at platform.xml after
the first invocation, the platform.xml has changed the site referring to
the directory to where the plugins moved to as platform:/base/. After using
the p2 installer, the platform.xml has changed even more, that is the features
listed from C:/eclipse-extension have just vanished. I don't explicitly
see any problems in eclipse with the changed platform.xml except maybe
this is contributing to the next issue as well.
Again, with this mocked-up scenario,
if we launch eclipse from a shared install, the p2 profile in the user's
configuration does not inherit the bundle-pool extension, causing the p2
installer to fail when installing new software, although eclipse itself
seems to be functional otherwise. Once, the profile property org.eclipse.equinox.p2.cache.extension
is fixed manually to add the C:/eclipse-extension, the p2 installer works
So, these are my questions - what should
we expect by way of platform:/base URL resolution and shared installs when
our installer relies on installing plugins in one folder and the eclipse
executable /configuration in another folder? Are there any recommendations?
I can provide a zip of my mocked up scenario, if desired.
p2-dev mailing list