Here's my advice for installing Eclipse onto a Linux box shared among multiple users. I see three solutions with varying amounts of disk space use / user control.
- Full User Control / Maximum Disk Usage
Each user installs their own Eclipse in
~/eclipse. This occupies maximum disk usage (perhaps as much as 400M per user), but allows each and every user to configure what plugins/features they need in their Eclipse. - No User Control / Minimum Disk Usage
Root performs a single central install of Eclipse in
/opt/eclipse(or their distro's preference). Minimal disk space needed, but users have NO control over updates or of what plugins/features they have access to, just their private workspace(s) in their home dir. This means that if you have some CDT users and some PDT users, everyone will be able to do everything -- and all users will have the same pile of plugins loaded on startup, regardless if they ever use those plugins. - Hybrid Install: Partial Control / Medium Disk Usage
Each user installs the Eclipse Platform Runtime Binary (~40M) in their
~/eclipse. All other plugins/features are installed into one or more "extension locations" in (for example)/opt/eclipse/modeling,/opt/eclipse/pde,/opt/eclipse/jdt,/opt/eclipse/pdt, etc.Users can then cherry-pick the feature groups (extension locations) they want depending on their needs via
Help > Software Updates > Manage Configuration > Add an Extension Location, but can't run updates -- only root can. This means everyone's install *could* be the same, but you could also have Modeling users, PDT users, and PDE/JDT users who only have installed to their Eclipse the plugins they actually need to perform their job.
If they need a feature that's not available in the common shared
/optspace, they can install it themselves into a new extension location, such as~/eclipse-plugins-phpeclipse. Then, if root notices that several users have downloaded and installed the same features, they could copy those features to/opt/and symlink the users' extension location folder(s) to the common folders in/opt/to save disk space.
In all three cases, I would also ensure that users have read the FAQ entries on starting Eclipse and tuning memory usage, so that as they add more features they don't crash their Eclipse or hog system resources. As root, it would be easy to create desktop shortcuts (and/or shell scripts) for a number of different canned Eclipse startup methods, using -vm /opt/jdk50/bin/java or -vm /opt/jdk60/bin/java, -data ~/workspace1 or -data ~/workspace2, and with -vmargs -Xmx256M -XX:PermSize=64M -XX:MaxPermSize=128M
This is how I would address this issue. How have other sysadmins solved this?
6 comments:
What about the current default behavior?
If you install eclipse in a directory where the user doesn't have write acess (such as /usr/local), a new extension location in ~/.eclipse is added automatically, and it's used for new plug-ins. This allows each user to install their own set of plug-ins, while also allowing a common subset of plugins to be maintained centrally.
This is kinda like your #2 but without the restriction on updating. Actually, how do you prevent users from creating their own update location in the first place? I remember seeing some info about that on some blog, and it involved hacking the update manager...
Or via the distro-provided packages? :)
Fedora:
yum install eclipse-sdk
... and various other packages.
Kim: didn't know about ~/.eclipse, thanks. As to preventing users from installing their own extensions, why would you want to?
Andrew: gah, I can't believe I forgot about the distro packages. Sorry! Speaking of which, when will the Europa packages be available? I don't see a plan/schedule on your wiki page. Should I be watching some other channel/feed/site?
Nick: I got the impression that it's what you described in #2 - having a single shared install, with no way of installing other plugins from eclipse. Never mind, my bad :-)
You're right, that is what I described. My point is simply -- in what situation would you want to prevent users from adding their own plugins?
Personally, I see #2 as being a suboptimal solution because of this restriction. #1 is also bad because of the disk space waste. #3 (or #4, install-by-distro-bundle) are the better options, IMHO.
Didn't know this document existed until now, but here's the official word on this subject.
Post a Comment