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

[klicnik@xxxxxxxxxx]

The details of the 2.0 story are not 100% nailed down yet. But the base 
structure is as follows:

* 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
* there is a new command argument -feature <id> that allows you to specify 
an identifier of the "primary feature" that gives the launched Eclipse its 
"personality" (splash, product customization info, etc). So if you say 
"eclipse -feature foo" eclipse comes up as foo, and if you say "eclipse 
-feature bar" eclipse comes up as bar. There are variations on this theme, 
in that the default feature can be pre-initialized, or a product packager 
can supply its own executable so that saying "foo" actually does the 
"eclipse -feature foo". The custom executable can also override the 
default splash handling.

The part that is still being worked are the exact details of the handshake 
between the executable launcher, the platform and what happens when the 
relevant information is updated using the update support (so the answer to 
you qestion about the exact location of the splash files is that it is 
being worked (current design (but not the builds) has these in the 
attribution plugin for the primary feature and that is likely where they 
will stay so they can be updated using the builtin mechanism)). The other 
part that is being worked are the details of the 2.0 version of the 
product.ini/ platform.ini/ about.html files and the corresponding usage of 
these.

Note, that in the above example, both "eclipse -feature foo" and "eclipse 
-feature bar" would run against the same install configuration (ie. same 
mix of plugins, just different personalization). There is also the ability 
for each of the 2 launch point to maintain its own configuration. Think of 
this as each of the launch points having their own managed plugin-path 
backed by the same install tree. In this way the launch points would 
result in 2 differently customized instances of Eclipse running a 
different mix of plugins.