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

[Peter Manahan <manahan@xxxxxxxxxx>]

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.

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 04:04 PM

Please respond to
eclipse-dev

To	eclipse-dev@xxxxxxxxxxx
cc
Subject	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.

<pm>
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.
        
</pm>


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
plugin.

<pm>
        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.
</pm>

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.
<pm>
        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.
<pm>

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.
<pm>
        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.

</pm>

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.

<pm>
        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.
</pm>
-alvin


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
> http://dev.eclipse.org/mailman/listinfo/eclipse-dev
> 
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
http://dev.eclipse.org/mailman/listinfo/eclipse-dev