Re: [platform-update-dev] Shared Install versus Shared Configuration

[Peter Manahan <manahan@xxxxxxxxxx>]

platform-update-dev-bounces@xxxxxxxxxxx wrote on 06/12/2007
12:23:24 PM:

> 
> Hi Peter, 
> 
> Thanks again for the reply.  It is good to talk to someone else
who 
> uses this stuff! 
> 
> OK, so I am once again thinking the *proper* thing we should be 
> doing is using a shared configuration area just as you describe.  
> However, there is one wrinkle with this approach that I have 
> encountered.  It seems to me that you also cannot update any
> existing features located in the shared install area of a "shared
> configuration" scenario - even as root - unless you manually
specify
> the shared configuration area on the command line.  I say this
> because the way we force a shared configuration (and when I say 
> shared configuration I am also implying that you are running in 
> cascaded configuration mode) is to add the following to the config.ini
> file in the eclipse/configuration folder: 
> 
> # Force a user-writable configuration location 
> osgi.configuration.area=@user.home/.
> eclipse/<productid>_<version>/configuration 
> 
> # Make the configuration area cascaded (may not be necessary) 
> osgi.configuration.cascaded=true 
> 
> In the course of figuring out how all of this works, I have noticed
> that we do not need to explicitly set osgi.sharedConfiguration.area
or 
> osgi.sharedConfiguration.area.readOnly as they are set automatically
> when the platform goes into cascaded mode.  In fact, I believe
as 
> long as there is a pre-populated (initialized) configuration area
in the 
> eclipse/configuration folder, as long as you specify a different 
> configuration area (using osgi.configuration.area) then you probably
> don't even need to set osgi.configuration.cascaded either. 

Right. We don't set any of those options and let it
be handled by default. We do set 

osgi.instance.area.default=@user.home/IBM/rationalsdp7.0/workspace

So that the workspace dialog is prepopulated in the
users area rather than the eclipse directory.

> 
> So, having the above lines in eclipse/configuration/config.ini, and
> assuming the eclipse/configuration folder also contains an 
> initialized, shared configuration area - if we want to be able to
> update features and plugins in the shared installation you will need
> to first of all be root or an administrator, and secondly run 
> Eclipse with the -configuration <path/to/>eclipse/configuration
> switch.  You may even need to add -vmargs -Dosgi.configuration.cascaded=false
> , I'm not sure.  So as I see it - in our case, we would want
to add 
> a second shortcut to our product that adds these command line 
> options that allows you to install updates via our update site - if
> you happen to be an administrator.  Otherwise, if you try to
run a 
> "check for updates" operation - it will always tell you
there are no
> updates (even if there are) because in cascaded mode, whether the
> directory is physically writable by you or not - Eclipse sets the
> shared configuration area to be non-updateable. 

We never set those options so the default for an admin
is to own the shared configuration area. We assume the admin doesn't actually
use the ide but only administors the machine , in fact we tell customers
that is how it should work. But if you did set those options then yes they'd
have to specify the shared configuration when wanting to administer it.
 A second administrator shortcut sounds like a good solution to deal
with it.


Peter

...
<snip>

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