Re: [platform-update-dev] Cascaded Configuration Areas

[Dorian Birsan <birsan@xxxxxxxxxx>]

> What do other companies do in this
situation?  Does *anybody* use cascaded configurations?


I'd be curious to know too. You seem
to live dangerously here, expecially given all the hacks you describe.
The main scenario that led to cascaded
configs was the following:  some admin installs eclipse to a readonly
location, then various users run it in their own local space. Each user
has his own configuration.Those user configuration are cascaded to use
the shared install, but each user can add new plugins in their local space.
The main shared eclipse is managed by
the admin only, users can't access it.
I have probably missed something in
your description, but is the above scenario broken (without hacking away
at config files, etc.) ?

Mark_Melvin@xxxxxxxx
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

06/08/2007 02:29 PM

Please respond to
"Eclipse Platform Update component developers list."        <platform-update-dev@xxxxxxxxxxx>

To	"Eclipse Platform Update component developers list." <platform-update-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-update-dev] Cascaded Configuration Areas

OK, so I just set up a local test as it does what you describe, Dorian....but
with an unexpected twist!

• If I run using a default cascaded configuration area (hence a read-only shared configuration area), when I search for updates it simply tells me there are no updates available (even though there are valid updates on the update site).
• If I override this and specify a configuration location pointing to my shared area (cascaded then flips to off all by itself), when I search for updates I get prompted for all of my new plugin versions and can install updates.
• *However*, going back to case #1 - I had faked this out with a policy file which re-directed all eclipse.org stuff so I didn't have to wait for mirrors.  Trying a cascaded configuration again, this time allowing Eclipse updates (I am running a 3.2.2 based product), it still does not find any "updates" for my plugins or for Eclipse, but it now tells me there are available PATCHES for Eclipse 3.2.2 (patch 1, 2, and 3).  Huh?  OK, just for kicks I try to install one.  Uh-oh!  It looks like it is going to go into the shared configuration area - which should be read only right now.  I click Finish anyway and kablammo!  It gives me an error telling me I cannot install the patch because my site is not updateable.

<sigh>  So am I the only one who finds this less that intuitive?
 First of all - why the different behaviour for patches?  And
second - if running in cascaded style (which is quite common I would think)
completely disables the update mechanism...well..to be frank - what is
the point of having an update mechanism??  If I have to specify a
different configuration on the command line, *and* log in as an administrator
to get write access to the folder anyway to install updates to my product
- well it seems to me that there is no point to having an update mechanism
because the updater will never find anything.  And it makes the "Automatic
Updates" feature especially useless because it will never find *anything*
except patches - which you can't install anyway.  You may as well
just have a "new feature" wizard and call it a day.  Although
this seems completely broken as well because if I search for "new"
features to install - it can potentially show me features that have version
numbers *older* than the ones I already have installed (I've verified this
by pointing Eclipse to an out-of-date update site)!  

What do other companies do in this situation?  Does *anybody* use
cascaded configurations? 

Mark.
----------------------------------------------------------


__________________ 

> > .............  What happens if I update a plugin using the
update 
> > manager?  Not install a new plugin, but actually run an
update 
> > operation that installs a newer version of a plugin that currently
> > resides in my read-only configuration area (one of the base Eclipse
> > plugins for instance)?  I'm assuming it will be installed
into my 
> > user configuration area and not be available to other users on
the 
> > machine? 
> 
> I don't recall the details, but I belive you can't update existing
> features/plugins because the updater will try to co-locate them with
> the old plugins. However, you should be able to install new plugins
> in a location of your choice. 

Hey Dorian, 

Thanks for the reply.  The only concern I have is the one above.  The
rest of the behaviour seems logical and desired, actually.  So - if
a user is running a cascaded configuration then installing updates is completely
diasabled/broken?  If this is true - what will it actually do (and
I will be testing this - I just need to set up something I can *update*
which is proving to be tricky right now)?  I mean - will it *try*
to update and just fail, or will it not allow updates to the features at
all?  I'm hoping the answer is c) none of the above and it will let
the user update the plugins into their user configuration area.  That
seems more logical to me.  Otherwise, why are we bothering to run
our own update site if the users have to become administrators and execute
a special command line (switching off cascading - which it turned on in
config.ini) in order to pick up updates to our plugins?  We may as
well just give them a link to download a new installer.

M. 
AMI Semiconductor - "Silicon Solutions for the
Real World"
NOTICE: 
This electronic message contains information that may be confidential or
privileged. The information is intended for the use of the individual or
entity named above. If you are not the intended recipient, please be aware
that any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you received this electronic message in error,
please notify the sender and delete the copy you received.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev