RE: [eclipse-dev] Purposal for the packages problem

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

This is feeling like a good direction.
 In the past we (the update team and me) have talked about having
an update manager which is able to work on configurations other than the
current one (i.e., the one it is running in).  I think there was interest
in that approach but it would be icing.   

One thing that has been missing from
the discussion is caching.  One thing that happens to me alot is I'm
on an airplane and need to make a new Eclipse install or I download the
zip and than at home (with no/slow net connection) install it.  To
address this I propose a simple caching approach where the update manager
optionally caches the jars it downloads in some user defined spot.  When
you go to install, the cache is consulted first for content.  installing
while offline is enabled, managing multiple configurations is somewhat
less painful (you've already downloaded the content but still have to start
each config and manage it).

We don't have much time in 3.0 so it
will really be for the update team to say how much time they have and what
they think should be done.  I will take the task of writing a bug
report either in Releng or Update to cover the discussion so far.  I'll
post the bug number later today.

Jeff

Peter Manahan/Toronto/IBM@IBMCA
Sent by: eclipse-dev-admin@xxxxxxxxxxx

02/13/2004 11:30 AM

Please respond to
eclipse-dev

To	eclipse-dev@xxxxxxxxxxx
cc
Subject	RE: [eclipse-dev] Purposal for the packages problem

eclipse-dev-admin@xxxxxxxxxxx wrote on 13/02/2004 10:53:50 AM:

> 
> 
> > So basically a RCP standalone update manager. 
> > That lives separately from the eclipse installation 
> > itself but can just "administor" your eclipse development
> > installations. 
> 
> Given Pascal's demo Equinox at EclipseCon, the standalone update manager
> could have the appearance of being "standalone" but could
actually be a
> small app which sits on top of the core and loads all of the other
features.
> Using this approach the update manager would be available both prior
to the
> install of the bulk of Eclipse, and also from within Eclipse Workbench
once
> the rest of Eclipse was installed. 

If you take that a little further and have a separate RCP applicaton to
do this work it could provide the ability to discover/update multiple eclipse
based installations on a user's machine. They could have an RCP business
application, eclipse 2.1.2, eclipse 3.0 M6, eclipse 3.0 M7 , WSAD ....
etc.  Basically it would decouple the version/instance of eclipse
running the update manager UI is running on from instance(s) eclipse of
 version you actually want update. It could actually solve many of
the problems that occur when you need update non-plugin/feature portions
of eclipse based applications. 

Something to consider anyway :-) 



-----------------------------------
Peter Manahan
IBM Rational Tools
Common Install
------------------------------------
manahan@xxxxxxxxxx