Community
Participate
Working Groups
Build ID: M20070212-1330 (Fedora Core release 6 (Zod)) Steps To Reproduce: Eclipse seems to store information on ~/.eclipse whithout to care about $XDG* environment variables More information: See http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
You might want to change it against 3.3 (or even 3.4), since no further work is likely to be done on 3.2. In any case, it's customisable. The property is taken from the entry in config.ini, which usually points to @user.data/workspace, but in your case sounds like it might be @user.data/.eclipse. The @ refers to a Java system property; I don't know if environment variables such as the one you quote might be there or not. It would be simple to launch Eclipse with "eclipse -data $XDB_BASE/.eclipse" if you wanted. This might well be a packaging issue for your distro, rather than Eclipse per se.
As Alex says, the directories where Eclipse writes data can be configured via command line arguments and/or system properties. Eclipse isn't going to build in special awareness of $XDG environment variables.
What is planned now about FreeDesktop XDG basedir specification for Eclipse? http://ploum.net/post/207-modify-your-application-to-use-xdg-folders https://live.gnome.org/GnomeGoals/XDGConfigFolders http://standards.freedesktop.org/basedir-spec/latest/
From the point of view of the committers involved, the plans have not evolved since the bug has been closed as wontfix. For my own education which linux distro implement this spec? Now by curiosity I glanced through the requirements (http://standards.freedesktop.org/basedir-spec/latest/ar01s02.html) to see what it required. My overall feeling is that from a pure runtime point of view, some things could be supported, however this would not make all the plugins work. This is because there are concepts that do not explicitely exist in eclipse as API and as such various plugins rolled out their own implementation (e.g. runtime caches). Here is a quick review of the reqs: > There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME. For eclipse I'm not sure what this folder would be. I would assume that this is the "workspace" in which case having just one does not make sense. For example when I work on two different projects, I need two different workspaces. The other thing that comes in mind are the preferences stored in the configuration folder. > There is a single base directory relative to which user-specific configuration files should be written. This directory is defined by the environment variable $XDG_CONFIG_HOME. This is supported by the -configuration option and which would immediately change the config scope in eclipse prefs. > There is a set of preference ordered base directories relative to which data files should be searched. This set of directories is defined by the environment variable $XDG_DATA_DIRS. Eclipse preference mechanism has the concept of scope, I suppose that additional scopes could be created and added to the default lookup order. However many plugins just look in one scope so they would not be affected. > There is a set of preference ordered base directories relative to which configuration files should be searched. This set of directories is defined by the environment variable $XDG_CONFIG_DIRS. Not sure how this would go with as Eclipse way of doing things that consists in loading configuration information on startup from two places and merge values. The only potential way would be to limit the config dirs to 2 and have the first one refer to -configuration and the other to the base configuration. Also if there is expectation around a merge or precedence this may not work. > There is a single base directory relative to which user-specific non-essential (cached) data should be written. This directory is defined by the environment variable $XDG_CACHE_HOME. There is no such concept. Currently application level caches are stored in sub folders of the configuration location. This is the responsibility of each plugin. A new concept would need to be added to Eclipse and adopted. > There is a single base directory relative to which user-specific runtime files and other file objects should be placed. This directory is defined by the environment variable $XDG_RUNTIME_DIR. This would apply to p2 for the dropins folder and for the location where bundles get downloaded when running in a shared install.
>For my own education which linux distro implement this spec? This spec is implemented by a lot of upstream applications including GNOME/GTK, KDE, XFCE, LXDE .... Thus nearly all distributions implement this spec. >> There is a single base directory relative to which user-specific configuration >>files should be written. This directory is defined by the environment variable >>$XDG_CONFIG_HOME. > This is supported by the -configuration option and which would immediately >change the config scope in eclipse prefs. -configuration option should default to $XDG_CONFIG_HOME/eclipse >> There is a single base directory relative to which user-specific non-essential >>(cached) data should be written. This directory is defined by the environment >>variable $XDG_CACHE_HOME. > There is no such concept. Currently application level caches are stored in sub >folders of the configuration location. This is the responsibility of each >plugin. A new concept would need to be added to Eclipse and adopted. A sigle cache dir is very important, because it can be easily excluded from backup
Thanks for the details. Given that the compliance would not be a matter of just settings a few flags (because concepts are missing). At this point I think that nothing will happen on this front unless a contribution is a done.
If you are waiting for a contrib, I suggest to reopen this bug.
Re-opening and flagging helpwanted
Ok, so it seems a thorough compliance would be difficult to achieve, but some parts are relatively easy. To start with, it should be simple - to make osgi.instance.area default to $XDG_DATA_HOME/eclipse/workspace_appId instead of @osgi.install.area/workspace - to make osgi.configuration.area default to $XDG_CONFIG_HOME/eclipse/appId_appVersion_installDirHash instead of $HOME/.eclipse/appId_appVersion_installDirHash (see bug 329587) - to make osgi.user.area default to $XDG_CONFIG_HOME/eclipse/common instead of $HOME/user Supporting $XDG_DATA_DIRS and $XDG_CONFIG_DIRS sounds feasible but would require more work, and introducing support for $XDG_CACHE_HOME and $XDG_RUNTIME_DIR sounds like a lot more work. Finally, I guess osgi.install.area also has to be split into $XDG_DATA_HOME and $XDG_CONFIG_HOME parts but that looks like yet one more separate work item that would have to take into account shared installations. I am writing this down to increase the chances that "simple" fixes make it into the code, and adding myself to cc in case I eventually get time to do them.
Would it make things easier from the Eclipse perspective if the XDG spec was modified to have one configuration and data directory instead of separate XDG_DATA_HOME and XDG_CONFIG_HOME? (cache would remain unchanged)
Disclaimer: I'm not an Eclipse committer but have experience of Eclipse plug-in development and use it regularly. Equinox platform, on top of which Eclipse is built, requires one to specify the following areas (see [1]): - instance, which is roughly equivalent to XDG_DATA_HOME + XDG_CACHE_HOME + XDG_RUNTIME_DIR, and which has to stay the same during application runtime but may change between startups. - configuration, which is equivalent to XDG_CONFIG_HOME and should be unique for each eclipse installation. - user, which is also equivalent to XDG_CONFIG_HOME and should be shared between different eclipse installations. So, I don't think merging XDG_DATA_HOME and XDG_CONFIG_HOME would help in any way, and I don't think it would create problems either. On a side note, there is also support for several hierarchical configuration areas, but I don't know if and how it can be integrated with XDG_CONFIG_DIRS. On the other hand, instance areas cannot be hierarchical as of now, and I am not sure there is need to support XDG_DATA_DIRS. [1] http://help.eclipse.org/kepler/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html#locations
*** Bug 453878 has been marked as a duplicate of this bug. ***
No plans to work on that.
