[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] External upgrades
- From: Daniel Jacobowitz <drow@xxxxxxxxx>
- Date: Sun, 12 Jul 2009 12:48:10 -0400
- Delivered-to: firstname.lastname@example.org
- User-agent: Mutt/1.5.20 (2009-06-14)
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
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
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.