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

[Mark_Melvin@xxxxxxxx]

OK, so I have found by grep'ing the
entire imported source tree that these readOnly
properties are used in the org.eclipse.osgi
plugin in the class org.eclipse.core.runtime.adaptor.LocationManger.
 I have also found by tracing through the source, that when you have
a cascaded configuration area - which implies that you have a "shared"
configuration area that is not NULL, *and* that your shared configuration
area is not the same as your normal configuration area - then the shared
configuration location is ALWAYS created as read-only.  I can see
no possible route in the code that allows a "shared" configuration
area to not be read-only.  Which begs the question - why is the property
there and documented in the first place?  I guess I should file a
bug.

This brings up another important question
though that I have yet to test (I'm still working on figuring out how much
of this stuff works as documented).  Let's say I am a non-administrative
user running Eclipse in a cascaded configuration (that implies that the
shared configuration is read-only) with a user configuration area that
I can write to.  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?  In particular,
I mean that the update will *not* be installed alongside the plugin that
it is updating because I cannot write there.  So I guess that means
that our installer (which installs things by running in headless mode)
will need to manually turn off cascading - or the updates will just be
installed in the administrator (or current user with administrative priviledges)
account's home directory and thus not be available to any other users on
the machine, correct?

I guess this also means that it will
not be possible to "update" your platform over the internet using
the update mechanism as an administrator and have those updates available
to all users - unless you manually turn off cascading when you run Eclipse
(similar to how our installer will have to function).

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

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

06/07/2007 03:28 PM

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

To	platform-update-dev@xxxxxxxxxxx
cc
Subject	[platform-update-dev] Cascaded Configuration Areas

Hi Everyone, 

I just posted the following (see the end of this email) to the platform
newsgroup but figured I may get a better response here.  But while
I am at it - I came across another (related) anomoly in the docs that I
can't seem to get to work at all.  The docs state that you can declare
configuration areas as read only by setting certain properties to 'true'.
 For example, setting osgi.sharedConfiguration.area.readOnly=true
is supposed to make your shared configuration area read only.  But
I can't get this to work, and I can't see any code that actually uses this
property or does anything with it.  The launcher code (Java) actually
attempts to write a file to the configuration area to see if it is read
only.  So apart from physically setting the area to be read only I
can't see a way to take advantage of the platform automatically calculating
a user configuration area for me.  Am I missing something?

I'm asking because I may have answered my original question below.  I
found this information in the docs: 

Setting the private configuration area location

The default location for a private configuration area is:

<user-home-dir>/.eclipse/<product-id>_<product-version>/configuration

The user home dir is determined by the user.home Java system property. The product id and version are obtained from the product marker file .eclipseproduct under the Eclipse install.

So it appears that the recommended way of specifying a user configuration area is to encode the product ID and product version into the path - which sort of answers my original question about multiple products accessing the same configuration area.  However, I don't have access to this information in any dynamic way so it would be nice to let the platform calculate it for me.  BUT - it appears from my failed attempts and grokking the source that this calculation *only* occurs if the shared configuration area is physically unwriteable, and setting those magical *.readOnly properties has no effect.

Thanks,
Mark.


<<original post>>


Hi There,
 
We are taking advantage of the cascaded configuration areas with our product and I have a fundamental question.  Let's say I release v1.0 of our product, and the user installs a master copy into C:\Program Files\<whatever>, and thus has a master "shared" configuration area initialized under C:\Program Files\<whatever>\eclipse\configuration.  The user will then maintain a user configuration area in c:\Documents and Settings\<user>\.eclipse\configuration.  This all works fine and user settings and plugins installed by the user go into their user configuration area.  Over the course of time the product is upgraded from 1.0 to 1.2, 1.2, 1.3, etc. - all of which is done with a proper installer on Windows, and the plugins in the shared configuration area are all properly updated using the Eclipse update mechanism.  The user configuration area detects and responds to changes in the master, shared configuration area and life is good.
 
Now what happens if I then release v2.0 of our product and it is intended to coexist with v1.x of our product, but I don't change the user configuration area to point to a new location?  I assume Eclipse is going to regenerate the appropriate files as required (in particular platform.xml), but will this work seamlessly in both directions?  Also, what if I run both products at once?  Will weird things happen?  I assume they will because the user-specific platform.xml has the following in it right now:
 
<config date="1181147819593" shared_ur="file:configuration/org.eclipse.update/platform.xml" transient="false" version="3.0">
</config>
 
If I run two products at the same time that are installed in two different folders (and thus the master, "shared" configuration area is different between the two products), but the user configuration area is the same - c:\Documents and Settings\<user>\.eclipse\configuration - I assume there will be contention on this file (in particular on the datestamp)?
 
What is the recommended way of doing this?  Any advice is appreciated.
 
Thanks,
Mark.
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

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.