RE: [platform-update-dev] Investigating some alternative update manager

[Peter Manahan <manahan@xxxxxxxxxx>]

All the problems below that Ed mentions are some of
the reasons we moved away from update manager as an install/update/deployment
mechanism for our eclipse IDE based products (RAD,RSA etc). Support "non-osgi/eclipse"
content in a first class way and the removing the line between initial
installation and update is key for future work imo. Most applications contain
a variety of content databases, windows com dll's etc. Some also contain
multiple eclipse or other runtimes which all need to be installed/updated
potentially together. 

The end user is the most important person in this
story and unlike eclipse ide itself the end user in many cases of install/update
is not a developer at all, even if they are installing eclipse ide. Just
something to keep in mind while thinking about this.

-- Peter

platform-update-dev-bounces@xxxxxxxxxxx wrote on 09/14/2006
11:11:23 AM:

> IMHO the biggest problem with the update manager today is it can't
> update everything. Just the other day I was trying to help a co-
> worker who reported that a plug-in I wrote wasn't working. It turned
> out she was running Eclipse 3.0 and the plug-in required 3.1 or 3.2.
> She had no idea she was running a back-level version of Eclipse. 
> "I've always run the update manager", she said, "and
I assumed it 
> would update me". I told her she had to install a whole new version
> of Eclipse so she did, and of course she unpacked it right on top
of
> the old version before I could stop her. So I had her redo it in a
> clean directory, but then she lost all the add-ins she had collected
> (like CodePro) and had to reinstall those. This kind of thing 
> happens all the time. I know exactly why it works this way but it's
> very user un-friendly.
> 
> The second biggest problem with the update manager today is it 
> doesn't deal with different versions of plug-ins that are targetted
> to different versions of Eclipse. Case in point. We have an internal
> update site for plug-ins that employees have written. Recently 
> someone wanted to upgrade an older plug-in to take advantage of a
> new feature in Eclipse 3.2. However they couldn't because users are
> running various versions of the Eclipse SDK including 3.0, 3.1, 3.2,
> or 3.3. And there's also the case of new Eclipse versions breaking
> old plug-ins that rely on internals (you know you write them). The
> manual work-around of having a different URL for each version of the
> SDK (updates/30, updates/31, etc.) is a pain to maintain and get 
> everyone to use it consistently and doesn't scale. There should be
a
> better way.
> 
> I wish I could help solve these problems with a code contribution
> but all I have time for right now is to complain about it and point
> to auto-updating programs like Firefox that seem to have solved it
> already. So if these kinds of issues can be addressed with "Update
> manager - TNG", that would be great.
> 
> --Ed
> www.pragmaticprogrammer.com/titles/ebgwt/
> _______________________________________________
> platform-update-dev mailing list
> platform-update-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-update-dev

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature