On 2011-01-20, at 8:23 AM, Mariusz Florek wrote:
Hi,
We are developing an application where we have to modify native launcher (f.e. eclipse.exe and corresponding eclipse*.dll).
I have a question according to p2 update: how to force p2 update to download and apply these changes to currently installed products (when .exe and .dll files change)?
p2 does not know how to replace eclipse.exe that are currently under use (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273127). This is open for contribution :)
For the dlls they are generally delivered in a plugin so this should not cause any problem. If you can't work around the previous bug, then I would recommend you to try to limit your changes to the .dll.
(how to prepare p2 repository to achieve it?)
This will take a lot of metadata tricking... Not necessarily because of p2, but because of the shape of the eclipse SDK metadata. Basically you will need to deliver a new bundle and then get it replaced everywhere.
For example on a mac, to replace the equivalent of the dll, you will need to rebuild
org.eclipse.equinox.launcher.cocoa.macosx.x86_64 (this is the IU for the fragment that contains the dll)
toolingorg.eclipse.equinox.launcher.cocoa.macosx.x86_64 (this is the CU that tells what to do with the dll (add arg in the eclipse.ini))
org.eclipse.rcp.configuration_root.cocoa.macosx.x86_64 (this is the IU that delivers the executable)
and them get them "inserted" in the metadata tree using a patch (you can try using the feature patch wizard, or you may want to try to directly create the beast using p2.inf, or write the XML by hand and get it added into the necessary repo...). The idea of a patch is equivalent to "rewriting" a particular requirement of a given IU. In this case the IU you will need to patch is org.eclipse.rcp.configuration.feature.group.
The other possibility is to completely regenerate an IU equivalent to org.eclipse.rcp.configuration.feature.group to include your new plugins. However this does not remove the need to patch, but you will have to patch the IU that requires that one.
(we are generating repository with ant task (because of obfuscating and signing plugins during product generation)
(we performing p2 update with p2 API)
We use eclipse 3.5.1 RCP version.
(we noticed 3.6 p2 API changed form 3.5 - does it contain helpful feature for the topic?)
The API changed that happen in 3.6 was to actually create an official API.
It will not make your particular task easier.
2. Will be p2 update possible when we port from 3.5 to 3.6 product?
Yes. We add an automated test that validated the update from 3.5 to 3.6.
So far, every version of p2 can read previous version of the p2 repositories.
HTH
