Re: [p2-dev] External upgrades

[Daniel Jacobowitz <drow@xxxxxxxxx>]

On Mon, Jul 06, 2009 at 07:31:35AM -0400, Daniel Jacobowitz wrote:
> We do our core product installation using an external tool, in this
> case InstallAnywhere.  This drops our entire product, including
> Eclipse, onto the system.  We also do in-place upgrades using
> InstallAnywhere.  With EUM this worked fine; the old Eclipse is
> removed, the configuration data and any user-installed plugins are
> left behind, a new Eclipse is dropped in, and -clean is enough to
> discover all the changes.  We even went from 3.3 to 3.4 this way
> (with p2 removed).
> 
> Everything I've read about p2 suggests this isn't going to work.
> It's going to find configuration data from the old Eclipse and not
> start the right features.
> 
> The one thing I'm sure of, though, is that this is a perfectly
> ordinary scenario.  We can't be alone in shipping Eclipse as part of a
> larger product, where relying on Eclipse's update mechanism isn't
> enough for the big picture.  Has anyone else addressed this problem?
> Can you force p2 to regenerate its configuration from installed
> bundles?

Hi all,

Does anyone have any comments on my scenario above?  p2 has been
included in two Eclipse releases now, and as far as I can see did not
support replacing the 3.4 platform with the 3.5 platform; so how do
other vendors plan to handle upgrades from 3.4-based to 3.5-based
products?

I've spent another week working on our p2 transition, and I'm
increasingly concerned about this.  So far, my best idea is to not
touch eclipse/p2 when upgrading, and programmatically replace IUs
modified by our installer.  But that sounds like a lot of fragile code
- I can't see how to approach it yet.

-- 
Daniel Jacobowitz
CodeSourcery