[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [platform-update-dev] Shared Install versus Shared Configuration


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=@xxxxxxxxx/.
> 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=@xxxxxxxxx/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