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

[klicnik@xxxxxxxxxx]

I think we are using the term "workspace" and "workbench" to mean the same 
thing ... the directory Eclipse uses to store the user projects and tool 
state. The relationships are as follows (using base Eclipse setup):

* you start with the eclipse.exe launcher. The location of the exe 
determines the default lookup for "things" that are not explicitly 
specified. So by default, the install location of the eclipse code is in 
plugins/* relative to the exe, the splash is in splash/* relative to the 
exe, and the workspace is created in workspace/ relative to the exe
* if you specify -data <path> this changes where the workspace will be 
found/ created if it does not exist
* the other 2 (splash and install) are changing in R2.0. For splash, this 
will be derived from the "-feature <id>" argument (there is no way to 
control this in R1.0). For the install tree, the R1.0 way is to specify 
"-boot <url>", or a combination of "-boot <url> -plugins <path>" (the 
second gives more precise control). In R2.0 there will be "-configuration 
<url>" that will allow the launch to control exactly what is used and from 
where (think of this as the R2.0 version of the plugin-path).

The currently posted spec is in need of updating. It is on my list of 
things to do soon. The spec is accurate in terms of the general approach/ 
structure, but is out of synch in some details (in particular the launch 
processing, native installers, specifically stating what is in 2.0 (the 
<group> support will not be in)).

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.   But of course... some questions back:

You said:
> * the location of the workspace does not matter .... you can set it up
> anywhere and specify -data <path> on launch, or you can let it default
> (which would not work if the product is installed in r/o space). There 
is

> no need to place the .exe in the workspace directory

In the last phrase - '.exe in the workspace directory' - do you mean .exe
in the Workbench directory?

Also - in reading the spec from 11/22/01 - there is a bit about where this
config info is stored:
> Eclipse Startup Processing

> Eclipse runtime instances execute from a shared program installation. 
The
startup
> configuration for each runtime instance is maintained as metadata in the
platform user area
> (the "root" directory structure used > to hold other Eclipse runtime
files, and the
> Eclipse workbench resources). The information is used at startup time as
a quick means
> for detecting "material" changes to the Eclipse installation, and to
compute the set
> of plug-ins (ie. the plug-in path) to be used for the Eclipse platform
execution. The
> configuration information is maintained by the installation and update
support.

If config info is stored in the workspace how will this impact people that
use the workbench against multiple different workspaces (different
roles/major projects).


Pat McCarthy   --   Eclipse Platform Enablement (3ECA)
                             --   OTI - RTP, NC
                             --   (919 254-6231 / 8-444-6231 -- FAX
8-444-4183)
                             --   Internet: PatMc@xxxxxxxxxx

                             --   Lotus: Pat McCarthy/Raleigh/IBM

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