Re: [platform-update-dev] Re: Launching branded products based on Workbe

["Pat McCarthy" <patmc@xxxxxxxxxx>]

Ok - that helps again.

My concern is (was?) that information on the available configurations was
written to the Workspace .metadata tree.   I may have multiple workspaces I
want to use by launching the desired config using either the -data d:
\ProjectA_Workspace or -data d:\ProjectB_Workspace parameter.

I don't think I want to have to manage replicating installed config
knowledge to multiple Workspaces.

In the same arena - regarding what the Platform writes after startup and
where this goes....

When I launch the Workbench on Windows (V2 - 01/25 build) I see these files
created in the e:\Eclipse\install dir:
      - install.properties
      - platform.cfg
      - update.cfg

In V1 we had install.properties in place as part of the branding - to id
the plug to be used for the config.  Now it is generated?


If I start the Software Update function these two files are also added to
the e:\Eclipse\install dir:
      - DefaultConfig.xml
      - LocalSite.xml

Right now if I configure a read-only instance of Eclipse:
      - I can start Eclipse only if I provide a r/w destination for the
Workspace (-data d:\newwork)
      - When I attempt to open the Update Manager it complains about not
being able to write DefaultConfig.xml


What is the role of these files and where else might they be stored/written
if the install target for the Eclipse platform is read-only to the user
that launches the platform?

Can these xml files, which I'm assuming will be related to the configs we
build for products on top of the base, be read-only or located in some
other common read/write area using a parm similar to -data?

Regards,

Pat McCarthy
PatMc@xxxxxxxxxx