Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Planning Meeting Notes - Nov 12, 2003

This should move this to platform-update-dev as this is where the much of the .config work was/is done.
 So as not to pollute up eclipse-dev anymore than it already is :-) Please direct all responses to platform-update-dev.

I've interjected a few remarks below <pm>.

Basically though the perspective I am coming at it from is a "product" one. That usually means
- minimal intervention on the part of the user.
- sysadmin friendly (unzipping a driver isn't friendly :-)
- out of the can configuration
- the novice user should be able to install the product (or installed by an admin) and run it easily.

An example is WSAD.
-  Installed as root into /opt/IBM/WebSphereStudio/..  (readonly location) by default
 - once the installed. All the user needs to do is type "wsappdev51" or selects the menu if one was created for that Desktop environment. WSAD launches and prompts for a workspace defaulting to a location in the users home directory. User hits ok splash screen shows up and the product launches with a correct workspace and a working configuration.

Eclipse isn't user friendly out-of-the-box anything at all to make it more so is goodness. Anything that makes it less so isn't. IMO of course :-)

So if we can help drive more multi-user friendliness into eclipse I am all for it.


Peter Manahan
WebSphere Tools
Build/Install and
Product Architecture

Alvin Thompson <al@xxxxxxxxxxxxxxxxx>
Sent by: eclipse-dev-admin@xxxxxxxxxxx

13/11/2003 04:04 PM

Please respond to

Re: [eclipse-dev] Planning Meeting Notes - Nov 12, 2003

i have two beefs with the current setup:

1. it complicates upgrading. if no data were in the actual program
directory, you could simply delete the old directory and unzip the new
version. very easy. also, if all the data needed for a particular user
(workspace, plugins, config) were in one place in your home dir, it
would be very easy and obvious to zip/cvs it all and take it with you,
recreating your complete environment on whatever computer you happen to
be working on (so long as eclipse was installed). in addition, if your
home dir were the default location for workspace/plugins/config, you
wouldn't need to mess with pesky '-data' switches, linking extension
locations, etc. just run the executable and it works. questions about
finding/changing workspace and plugin locations are probably the most
common among eclipse newbies. if these files were in your home dir 80%
of these questions would go away.

Agree it shouldn't be in the program directory. I disagree with putting
system information in everyone's home dir. That should be for user information only.
Since its a shared component it should have shared config and a user config. It is
changing for 3.0 to be more like that I think. Escpecially wouldn't want to put
the actual plugins in a home directory. Some of the plugin sets people ship
approach 100 MB.

Agree the home dir is a better place for the workspace than the current directory.
I tend to never keep anything except config in my home dir so I think even better
IMO is a custom directory location. WSAD for example pops up a dialog asking
where the workspace should go. The eclipse executable could do the same. Saves the
information of where the workspace is in the users home directory.

Disagree with unzipping the drivers into some file system location and calling it
installed. I understand why, but there are two audiences
1) professional users  those who can go the distance. Get thier hands dirty etc
2) all other users. For the most part products like WSAD need
to worry about the latter. Systems are administrated by a professional admin and
users are not allowed to be root etc or to install software. This is the way it is in
many corporations. So a real install of somesort is required. And when you install
something you can also configure it for all users on the system. Ie a default
configuration. We get asked for this all the time.        

2. a shared program dir should not be writable. at the very least this
compromises security. and on most *nix systems regular users won't have
write access to the install location. right now not only is the
'.config' dir written to, but the installation dir is the default
install location for features. unacceptable. users with write access
should be given the options to install plugins for all users, but the
default location should always be your home directory. many plugins
don't play well with other plugins or just plain royally screw stuff up;
users should not be allowed to hose everyone if they install some hosed

        I had thought they added code in 2.1 not to show the default location
        if it was read only. I actually don't think there should be a default location
        but if I was really pushed for one I think the home directory would be a logical
        choice. Hopefully the talk of a policy file to control where/when and how updates
        occur for 3.0 will take this into consideration.

as far as the '.config' dir is concerned, if it were created/written
once during installation and never written to again, that would be ok.
but i don't think that's the case. i use the '-data' switch to keep my
workspace elsewhere, and i add my plugins to a separate extension
location. but, if i try to upgrade by removing the old dir and
unzipping, it 'forgets' the location of the plugins. eclipse must keep
some plugin information inside of that '.config' dir, which means it's
writing to it after installation.

        The .config should only be written once. Currently eclipse keeps user .config
        information in the workspace. The original one should never be written to.
        Thats why eclipse loses any information not contained in the initial/system one
        when you switch workspaces. Eclipse needs to have a
        user .config directory rather than a workspace .config directory idea.
        I am not sure how far the -configuration flag will take you in
        that direction.

the '-configuration' switch does not work on my win2k box; it puts
eclipse into an endless loop trying to start. it flashes the
'initializing' splash screen on and off repeatedly.

        Looks like i gave slightly incorrect instructions.Doh! sorry
        Using 2.1.2 (its supposed to be a file url).
        eclipse -configuration file:D:/eclipse/cfg/plt.cfg -vm d:\java\java131\bin\javaw.exe -data d:\eclipse\wstst1
        this worked for me. It seems the -initialize flag always creates it in the eclipse dir.

if the '.config' dir is only written to during installation/first use,
it can just as easily be placed in the user's home directory. the only
cost is that the 'initializing' splash screen will show up the first
time every user runs. i imagine the directory was moved into the eclipse
dir because it now needs to be recreated when a new version of the
program is first started. that can easily be done by including version
info in the directory. upon startup, eclipse checks the version of the
directory. if the version doesn't match, eclipse should delete the
directory and recreate it.

        The requirement was never to see the completing the install
        splash screen. So having it come up each time a user started
        a new workspace was a bad thing. The .config directory created
        when you use -initialize was specifically to prevent that and to
        give new workspaces a base configuration. Since they are moving
        much configuration information out of the workspace in 3.0
        perhaps this one of the ones being moved out.

Peter Manahan wrote:

> I am not sure I understand what all the fuss is about.  The .config dir
> is not user information. It is eclipse system configuration. Allowing
> general users to modify that is like allowing just anyone to write to
> the /etc dir.
>  Using 2.1.2 as a basis (this is changing slightly in 3.0 as config
> information is moving out of the workspace. or so i hear)
> 1) root installs eclipse and in that process creates the .config via
> eclipse -initialize -data /tmp/workspace
> 2) user runs eclipse without error.
> for purists this is supposed to work (requires a wrapped eclipse
> launcher)  
> 1) root install of eclipse
> 2) root then creates the .config in say /etc/eclipse/.config using the
> -configuration flag "eclipse -initialize -data /tmp/workspace/
> -configuration /etc/eclipse"
> 3) user runs without error using the eclipse -configuration
> /etc/eclipse/   -data $HOME/workspace.
> What eclipse is missing is the user portion of this which right now is
> per  workspace rather than per user.
> Of the four basic types of configuration (system,instance, user, user
> instance ) eclipse seems to have only two
> (system =.config , user instance = workspace). At least in 2.1.2.
> I understand in 3.0 they'll have instead (system ,user )? I think.
> Thanks,
> -----------------------------------
> Peter Manahan
> WebSphere Tools
> Build/Install and
> Product Architecture
> ------------------------------------
> manahan@xxxxxxxxxx
> *Alvin Thompson <al@xxxxxxxxxxxxxxxxx>*
> Sent by: eclipse-dev-admin@xxxxxxxxxxx
> 13/11/2003 12:59 PM
> Please respond to
> eclipse-dev
> To
>                  Andrew Haley <aph@xxxxxxxxxx>
> cc
>                  eclipse-dev@xxxxxxxxxxx
> Subject
>                  Re: [eclipse-dev] Planning Meeting Notes - Nov 12, 2003
> eclipse itself should default to this behavior. what's the point of
> writing stuff to the program directory instead of the user directory?
> -alvin
> Andrew Haley wrote:
>  > I submitted a patch for this an age ago; it's in Red Hat's version of
>  > Eclipse.
>  >
>  > Andrew.
>  >
> _______________________________________________
> eclipse-dev mailing list
> eclipse-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top