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

["Chris" <celek@xxxxxxxxxx>]

 Hi Pat,

>
>
> Ok - that helps again.
>

 [snip]

> 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 ?

the newly generated file is platform.cfg, I believe the old one should
disappear

>
> 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
>

Yep, this is a bug in the latest integration driver where I attempt to write
in a directory that doesn't exist yet.
Should be fixed in next.

> 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?

Roles:
LocalSite.xml contains the history of your installConfiguration. An install
configuration is a set of sites and their associated configured and
unconfigured features. The DefaultConfig (soon will change name) is the
first InstallConfiguration.

Save:
Just noticed that too... I am not sure how we can behave (beside not saving
file)
1) we just do not do anything and the user cannot use the Update (grayed
out)
2) somewhere somehow we manage it into another location, while inheriting
properties from the r/o one.

> 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?

I do not believe they are related to the configuration, they are saved by
Update tool when an action occurs (add/remove site, add/remove feature,
configure/unconfigure feature) It is the persistence of the Update Model...

Let us know

Chris