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

[Mark_Melvin@xxxxxxxx]

Hi Dorian,

I think the scenario you describe still
works.  Maybe I'll describe my scenario then and someone can tell
me the proper way to implement it... ;o)

All we want to do is have our Windows-based
installer install a set of plugins and features (along with a base Eclipse
install and JRE).  We currently require administrator access and install
this into C:\Program Files\<blah blah>.  Now we want this installation
to be done as an administrator and then essentially be read-only from then
on.  Now other users (non-admin) can log into the machine and have
all of their user-specific settings stored in their home folders.  If
they want to install new plugins they should be able to.  This currently
works too, if they have appropriate access to write to the C:\Program Files
area.  More on this later.  
But part of the whole scenario is the
ability to auto-update.  When new versions of our plugins are available
(or of the Eclipse platform) the user should be able to upgrade using the
Eclipse update mechanism.  Now - I guess it is unclear whether this
should be a user-specific thing, or whether the user should be forced to
log in as an administrator to update their product.  

The problem we initially had was that
we were running with a normal configuration area in the installation folder.
 If a user was a power user, Eclipse would dump junk in this folder
(which was undesireable).   If the user was not a power user, Eclipse
would automatically dump junk into their home folder (going into cascaded
mode automatically if the user did not have write access to the installation
location).  So then we decided to switch horses and go with "Scenario
#2" in the docs - the shared install.

This appeared to work, but we recently
ran into a problem.  Our installer can "update" an existing
installation with new features, and we were finding that after you updated
your exisiting product installation with new features (as an administrator),
when you logged back in as a regular user they were not being detected.
 You had to actually run a -clean operation in order to find them.
 At this point I sort of made the assumption that we really *should*
be using was a cascaded or shared configuration (Scenario #3 in
the docs) and I have been cranking on migrating our installer to work that
way.  I figured this would not only solve the -clean issue but it
would also solve the issue of users installing their own third-party plugins.
 It all seemed to function great (after bug #190533 was fixed), but
I never thought about the whole updating via an update site issue.  I
didn't realize the whole can of worms I was about to open...  

So, it appears that perhaps I have been
running in circles the past few days and what we *really* want is to continue
using Scenario #2 - a shared install, but figure out why users need
to issue a -clean to pick them up.  But the issue I have then is -
what happens when a power user versus a regular user installs third-party
plugins?  It seems to me that if you have write access to the installation
folder - Eclipse dumps them there.  If not...well I have never tried
this with a shared install scenario.  I assume it will go into your
user configuration area?

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

Dorian Birsan <birsan@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx

06/08/2007 02:58 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

> 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
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev

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.