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

[klicnik@xxxxxxxxxx]

Pat, what you are seeing right now if a mix of R1 and R2 behavior because 
of where we are in development. This stuff will continue to change over 
the next 2 months, so don't pay much attention to what is happening today. 
A brief summary of what these files are/ where they need to be ...

=> update.cfg (and its variations) ... R1.0 config file, should be gone as 
of about driver 20020205 (possibly the one before)
=> platform.cfg ... R2.0 config file, must be in r/w space if you want to 
be able to update the config, but platform will come up with it in r/o. 
Can be explicitly specified (-configuration) or will be located based on 
search sequence (evolving, currently user.dir, then user.home, then within 
install tree), if not found, defaults to install tree (but if this is r/o 
then the first note applies ... will come up with defaults, but not save/ 
be able to update)
=> *.xml ... R2.0 install/update state, always created (or attempted to be 
created) relative to wherever platform.cfg was found. Sounds like we need 
to be a bit more gracefull when we failt to write
=> install.properties ... if supplied by install, used to initialize 
defaults on firdst startup, is always written/ rewritten on shutdown to 
contain a snapshot of the current bootstrap values (R1 and R2). This one 
will be used in the exe launcher handshake with the platform support and 
the details are evolving.

Please respond to platform-update-dev@xxxxxxxxxxx 
Sent by:        platform-update-dev-admin@xxxxxxxxxxx
To:     platform-update-dev@xxxxxxxxxxx
cc: 
Subject:        Re: [platform-update-dev] Re: Launching branded products based on 
Workbench



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


_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev