views:

45

answers:

1

I have a Eclipse-based project (the Scala IDE for Eclipse) which has recently moved to a new home. I want to change the various feature ids, Bundle-SymbolicNames etc. to reflect the move (ie. so that they all have an org.scala-ide prefix) and restart the version numbering (previously it was tied to the corresponding Scala compiler release and I want to decouple these).

But I want p2 to recognize that, eg. org.scala-ide.sdt.feature v. 1.0.0 is an upgrade of ch.epfl.lamp.sdt v. 2.7.7. With RPM it would be possible to do this using an obsoletes directive ... is there an equivalent for p2?

+2  A: 

I believe this is possible, but there is currently no tooling (or documentation) for it.

Each IU contains an Update Descriptor (javadoc) which indicates which IU it is an update of. The existing tooling always sets this to be previous versions of the same bundle. In the content.xml it looks like this:

<unit id='org.eclipse.equinox.launcher' version='1.1.0.v20100507'>
   <update id='org.eclipse.equinox.launcher' range='[0.0.0,1.1.0.v20100507)' severity='0'/>
   ...

To set this you could

  1. Wait for bug 282545 to get fixed.
  2. Edit the content.xml manually (perhaps an xslt transform)
  3. Extend the p2 publisher to generate a different descriptor. You would want to override BundlesAction to use your own version of BundlesAction#createBundleIU.
Andrew Niefer
Fantastic ... thanks.
Miles Sabin
Unfortunately, this doesn't seem to work, at least, not in all circumstances. The update elements don't appear to be tested at the appropriate point during during the install/upgrade process, with the result that both old and new features are retained as part of the provisioning plan (we want the old features to be selected for removal).In the end I've created dummy implementations of the old features which are optionally included in the new ones. This allows the new features to update the old ones with the possibility of eliminating them completely later.
Miles Sabin