Forgive me Update Manager, for I have sinned
Never one to shy away from admitting my mistakes, I’d like to draw attention to something that could have been handled more cleanly: migration of EMF and EMFT into Modeling.
Two bugs have been raised (and since closed) on this topic:
- Bug 170402: EMF Updates get “403 Forbidden”
- Bug 205051: EMFT update site is obsolete
The problem, ultimately, is that old clients can’t update to use the new URL unless the new version exists on BOTH the old site and the new site. For example, EMF 2.2.3’s SDK feature had this:
<url>
<update label="%EMFUpdateSiteName" url="http://download.eclipse.org/modeling/emf/updates/"/>
<discovery label="%EMFTUpdateSiteName" url="http://download.eclipse.org/technology/emft/updates/"/>
</url>
So it’s an easy fix to spin EMF 2.2.4, which provides a new discovery URL at /modeling/emft/ instead.
But for EMF 2.1.2, which had:
<url>
<update label="%secondaryUpdateSiteName" url="http://download.eclipse.org/tools/emf/updates/"/>
<discovery label="%secondaryUpdateSiteName" url="http://download.eclipse.org/tools/emf/updates/"/>
</url>
Updating to 2.1.3 poses a bigger problem in that 2.1.3 is NOT provided on the old /tools/emf/ site, but on the /modeling/emf/ site.
What could I have done differently? Well, not much beyond putting the same xml and jars on both the new and old sites, which I still consider a somewhat unclean (if effective) solution as it’s a waste of bandwidth for both download.eclipse.org and the mirrors. Here are three other ways to solve this problem, which I could have documented better so that users would be more aware of how to get their updates despite the move:
- Update using ’search for new’ instead of ’search for updates’, adding the new update site [1].
- Install, just this once, from the zip instead of with Update [2].
- Use a policy file to force Eclipse to go hunting for updates from the new URL [3].
Knowing nothing about what’s in or out of scope for the Equinox p2 effort, I’d like to fondly wish that they’ll consider a way around this problem, like allowing users to enter a replacement URL for a feature that’s not updateable from its old URL, or simply failing gracefully without preventing the rest of the updates to be carried out. But as there are three workarounds, I’ll leave it to someone else to file a bug report if they consider Update site moves to be a big enough problem to warrant a bug or feature request.
Anyway, I’m hoping that this bit of penance will save others from making my mistake if/when they graduate from one project to another (eg., from technology or tools). Unfortunately, EMFT components will regularly have to undergo this transition as they graduate out of incubation, every year or two.
Posted October 16th, 2007 by in category: errata, features, update manager, usability, web
You can skip to the end and leave a response. Pinging is currently not allowed.
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
