Community
Participate
Working Groups
In a multiuser environment it isn't possible to have a linked in folder for a user. You can put additional shared plugins into /usr/lokal/ and link this, but it is not possible to link to for example $HOME/eclipse A comandline parameter along the -data one would be nice for this. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186725
I'm not sure I fully understand your request...can you elaborate further? The -configuration parameter allows you to specify additional plug-ins to take into consideration when starting up your Eclipse environment. Is this what you are looking for?
If I read http://download2.eclipse.org/downloads/documentation/2.0/html/plugins/org.eclipse.platform.doc.user/tasks/running_eclipse.htm right, it only lets me startup the primary feature and such things. Currently the setup on a multiuser Linux box looks like this: The original eclipse is in /usr/lib/eclipse (debian packages) and in the subfolder links is a .link to /usr/local to install plugins into a location, where apt-get (debian package manager) isn't complainig about it. The problem is, that a normal user can't put some new/additional plugins there. For normal users you would need a linked-in folder in $HOME, but that isn't possible, because eclipse expects a absolute path to this folder. It would also be nice, if it would be possible to set this location as the only one, where the eclipse update manager could place new features/plugins or update them.
Ok, to make it clearer what I mean here is a patch against org.eclipse.core. internal.boot.PlaformConfiguration. With this patch eclipse now starts up with the root site not updateable (i just did this for the debian packages...). Also you can now start eclipse with a '-addsite <Url to a dir or a user.links file>' param. If a dir is given, the dir is used like the 'path' property in the <eclipse dir>/links/*.links files with updateable = true. If a file is specified, it is handled like a *.links file in <eclipse dir>/links and you can specifiy rw/r in the property file.
Created attachment 4708 [details] new -addsite param
Ok, this patch still has a bug: I doesn't change the site entry in platform.cfg, if the admin changes the links/*.links file or the user changes there -addsite specified link file (ro/rw) or a location gets deleted. For this configureSite(site) should call configureSite(site, true) instead of configureSite(site,false), so that the last added one wins. I'm also thinking that the SiteEntry#isExternallyLinkedSite() is probably not working, when -addsite is used (or just a manually changed platform.cfg). I'm not sure, but I think that eclipse currently isn't well designed in that respect. ATM eclipse can't really be installed on a *ix PC by a admin without users touching 'package manager' managed dirs (via updatemanager; I haven't tested, but this will most likely give a Exception about no write access, but anyway...). Also, if I read the code right, added sites via links/*.links are kept in the platform.cfg, even if the admin deletes this file again (same would go with my patch and -addsite). Eclipse should be more multiuser system aware. Just my 2 Cent...
vote +1 for multiuser system awareness
Pascal, this is perhaps something to consider for Equinox runtime?
Created attachment 6146 [details] Latest version of teh patch This is the latest version directly form my debian packages.
Any updates on this? Is this integrated in the OSI (sp?) rewrite? IMO this patch is relativly save, as it only does some refactoring and add a new param in the param parser. The only change is how the platform.cfg entries are 'installed' (-> they are overwritten by the filesystem (*.links) or commandline entries) at runtime. Jan
This issues was also raised in https://bugs.eclipse.org/bugs/show_bug.cgi?id=35037 The consensus there was leaning towards adding variable expansion in the link paths, but the resolution was to do this 'LATER'. I guess now is finally LATER. The solution proposed was to allow property name references to be expanded in link paths. For example path = ${user.home}/myfeature would point to a myfeature directory (if found) in each user's home directory, while path = ${mylink} would point to the directory pointed to using -Dmylink=XXXXX at the command-line using -vmargs. The ${propertyname} reference syntax is consistent with other systems such as Ant and java security mgr files.
re #10: Is that already integrated into the latest eclipse?
M8 contains this notice: --- When Eclipse is installed for shared use, such as on Unix/Linux, the user platform configuration is "cascaded" with the shared configuration. This way, updates made the administrators will automatically be picked up by users upon restart. --- Does this also mean, that plugin dirs in $HOME are now possible?
This bug seems to have fallen in the cracks of bugzilla - possibly because it's marked against 2.1. Can someone comment on if this bug is still present in 3.0 and if there is any interest in incorporating the attached patches into 3.1. Thanks.
In shared install scenarios, a user can install plugins using the update manager and he will have the opportunity to choose where those plugins should go. Therefore, nothing should prevent the installation to be done in $HOME.
Great. I just tried it out and it seems to work. If Jan is ok with it, perhaps this bug should be closed.
Yes, I'm fine with it :) Closing as fixed
