| Blocking problems w/a p2 based RCP product-Updates locked/feature install breaks [message #48130] |
Wed, 25 February 2009 12:43  |
Eclipse User |
|
|
|
Ive been leading the charge in moving our company's product over to use
Eclipse 3.4 and P2 as our base (and new update mechanism) - we've been
building on top of Eclipse 3.2.2 for two years now and our users are
rightly demanding we move forward. Weve been running into a number of
issues and oddities in getting the 3.4 based product working properly,
though.
Were building our product against 3.4 and then using the p2 director app
to generate the standalone product on our build machine. We have the
following hierarchy:
com.aptana.ide.rcp.product
|-com.aptana.ide.feature.rcp
|- com.aptana.ide.feature
|- org.eclipse.platform
We build com.aptana.ide.feature for use when plugging into Eclipse and
generate an update site for that. We build com.aptana.ide.rcp.product as a
product, with an update site. A third build then triggers and uses the
p2.director to generate standalone products from the product builds
update site. We zip those up per OS/Arch combo (and also re-purpose those
for installers).
Theres been a number of odd issues weve run into. Here's the blockers:
- When we specify a custom osgi.configuration.area under the users home
directory in the config.ini, the product IU and a pro feature we
pre-install are both marked as locked for updates, so even though updates
are found by automatic update check, theyre ignored as invalid.
- If we dont specify a separate config area we dont have that issue any
more, but after the first install of any feature via the P2 APIs, the
product wont start back up again properly. It appears that the config.ini
gets changed and the osgi.bundles property is changed to list the newly
installed plugins (whereas before it pointed to the simpleconfigurator
plugin which used the bundles.info listing).
So, if we specify a custom osgi.configuration area our pre-installed
features and product can't be update. If we don't, then after a feature is
installed the product won't start up all the plugins properly.
-Chris
|
|
|
| Re: Blocking problems w/a p2 based RCP product-Updates locked/feature install br [message #49205 is a reply to message #48130] |
Wed, 04 March 2009 11:24  |
| Eclipse User |
|
|
|
Chris Williams wrote:
> Theres been a number of odd issues weve run into. Here's the blockers:
...
> - If we dont specify a separate config area we dont have that issue any
> more, but after the first install of any feature via the P2 APIs, the
> product wont start back up again properly. It appears that the config.ini
> gets changed and the osgi.bundles property is changed to list the newly
> installed plugins (whereas before it pointed to the simpleconfigurator
> plugin which used the bundles.info listing).
To circle back with some extra info/workaround: I filed
https://bugs.eclipse.org/bugs/show_bug.cgi?id=266222 related to this. The
issue is that the p2 metadata is not being generated for the Mac launcher.
Until it's resolved our workaround was to un-jar the metadata, add the
entries necessary for the mac launcher and then re-jar during a post build
target (using some tricky replaceregexp).
|
|
|
| Re: Blocking problems w/a p2 based RCP product-Updates locked/feature install br [message #592740 is a reply to message #48130] |
Wed, 04 March 2009 11:24 |
| Eclipse User |
|
|
|
Chris Williams wrote:
> Theres been a number of odd issues weve run into. Here's the blockers:
...
> - If we dont specify a separate config area we dont have that issue any
> more, but after the first install of any feature via the P2 APIs, the
> product wont start back up again properly. It appears that the config.ini
> gets changed and the osgi.bundles property is changed to list the newly
> installed plugins (whereas before it pointed to the simpleconfigurator
> plugin which used the bundles.info listing).
To circle back with some extra info/workaround: I filed
https://bugs.eclipse.org/bugs/show_bug.cgi?id=266222 related to this. The
issue is that the p2 metadata is not being generated for the Mac launcher.
Until it's resolved our workaround was to un-jar the metadata, add the
entries necessary for the mac launcher and then re-jar during a post build
target (using some tricky replaceregexp).
|
|
|
Powered by
FUDForum. Page generated in 0.06146 seconds
Home