Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] platform:/base URL resolution and shared installs inheriting bundle-pool extensions in Eclipse 3.5/3.6


Would like to add, for the mocked up eclipse, the references to plugins/ in bundles.info were replaced by file:C:/eclipse-extensions/plugins/ too.

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,
Nalini.


From: Nalini Ganapati/Beaverton/IBM@IBMUS
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date: 12/10/2009 10:39 AM
Subject: [p2-dev] platform:/base URL resolution and shared installs inheriting bundle-pool extensions in Eclipse 3.5/3.6
Sent by: p2-dev-bounces@xxxxxxxxxxx





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 fine.

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.

Thanks,

Nalini. _______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


Back to the top