Re: [platform-update-dev] Is there a need: optional features - disabled

["Pat McCarthy" <patmc@xxxxxxxxxx>]

You said:
"Try as I might, I cannot recall an example where I was asked to select
optional portions of a product, then was not able to use them when the
installation was complete."

My memory of VAJava was that we had to install all possible features,
things like persistence builder, and so on.  Then we had to start the
product and load them into our workspace (a huge resource crunch,
especially for some of the features I used to load - (read two coffee's)).
At least that is my memory (faint as it is now).

So, I see that as the pattern; available, but not yet integrated into how
the Eclipse platform works (but I'm happy with my process as used on my
machine).

As for installed but not yet there - it would be done up-front, either
directly by an advanced user/administrator or by each user, as they
selected the option to make these features ready to go, but not active.

The user will need to be aware of their configuration.  I think we need to
show them a bit of respect with regards to how they can grow to become
active participants in managing their platform.

The real goal with this approach is how can I get a config that can grow to
any possible state without having to chase down the CD.  I'm assuming that
most shops that use WSxx tools will not install PDE at first, but once they
learn about what it can do, will want to try it out.  Having it 'lurking'
in the disabled list makes this easy.

Side question that came out of some experiments - how can a user of a
shared install (Linux or R/O share on Windows) get a default configuration
other than the one defined in the shared install?  Looks like I'd have to
add my new/extra features to every workspace I open using Update Manager -
I can't use link files nor can I run -initialize to a private user area.
Just something I'm noodling on a bit...

Pat McCarthy