Community
Participate
Working Groups
Since this is what all other Unix apps do, Eclipse should default to storing its metadata i $HOME/.eclipse (instead of workspace/.metadata). Having Eclipse doing things differently from all other apps is confusing.
*** Bug 28936 has been marked as a duplicate of this bug. ***
Not just confusing, but annoying, and I accidently lost the information there (dup bug) because of that. If you fix this bug, then please also create ~/workspace/ only as necessary (i.e. if I create a project there).
This should also be the case for Windows apps (and Mac OS X apps) as well. Deleting and reinstalling Eclipse from the install path /shouldn't/ trash all of the workspace metadata, and certainly the default for storing project's files shouldn't be in this directory.
I agree. In fact, this is a flaw in all the versions of Eclipse, for all OS. The workspace should NOT come under the install directory. Period. It's a basic rule of application development not to store data files with binary files. Under UNIX style OS creating the workspace under .eclipse/workspace by default should take place. However, a better solution in general would be that, the first time Eclipse starts it should ask you where you want yo put your workspace. It should then store that directory somewhere OS specific (~/.eclipse/workspace.ini under Unix style OS and in the registry under HKCU for Windows. Then, whenever Eclipse is started and this entry / file exists it should be used. This is much better than having to remember not to accidentally delete your workspace! Chz
*** Bug 11992 has been marked as a duplicate of this bug. ***
I don't think metadata should be stored under $HOME/.eclipse. I use more than one workspace and in fact many of the workspaces have different settings for accessing version control, for compiling projects etc. Having everything under $HOME/.eclipse would a) result in much work when trying to setup independent workspaces and b) make it impossible to backup a workspace as whole. However, it may make sense to have the complete (default) workspace stores under $HOME... PS: What about negative votes? ;)
The ability to have multiple workspaces would be benficial; it may be possible to do that with some kind of command-line switch for specifying an alternate workspace? It also raises the question about having two installs of Eclipse; say, one for testing purposes (e.g. downloading latest integration builds) and one for `regular' use. However, IMHO still having the (default) data under ${HOME} is a good thing, but perhaps with the options of having alternatives elsewhere ... Not sure about not being able to backup a workspace; what would be wrong with just copying .eclipse? Also, accessing CVS (for example) is configured on a project-by-project basis rather than Eclipse as a whole, isn't it?
This bug should be changed to reflect all OS, not just Unix flavours. Should be put in ${java.home} on all platforms, not just the Unices.
I don't see how changing the (deault) *location* of the metadata (from ~/workspace/.metadata to ~/.eclipse) would impair on your ability to have multiple workspaces. For me, the assumption is that everything in home starting with normal chars is managed by me, the user, and can be changed/moved around/deleted at will, while dirs and files in home starting with a dot are managed by the programs and removing it will reset the app to its state after installation (and changing it might break the app). This is what requested here, to change the default location to match that convention to avoid data loss.
I read the original comment (and blocked bug 26756) that the workspace/metadata should be stored in the user's home directory, and not where Eclipse was installed/launched from (as it currently is). Having ${java.home}/workspace/.eclipse for the metatdata sounds like a good idea, but the important thing is that it's relative to ${java.home} rather than `pwd' IMHO 'workspace' wouldn't be the first choice of a directory for the Eclipse workspace; what about ~/eclipse/.metadata instead?
> what about ~/eclipse/.metadata instead? Doesn't change much to the current state. See my previous comments. If every app unloaded its crap in my homedir (as normal dirs/files, not dotfiles), it would soon be unusable.
It seems like there are three separate issues: 1. Eclipse should default to storing the workspace in user's $HOME directory (or more to the point, *anywhere but the install directory* !!!) 2. Eclipse should put the .metadata somewhere else 3. Eclipse should ask the user on first launch where to put the workspace I think that #2 is irrelevant compared to #1, and um, shouldn't the metadata just be under the workspace, wherever the workspace ends up? It's too bad bug 11992 was closed, since that one clearly says "Eclipse should default to storing the workspace in user's $HOME directory" instead of clouding the issue with metadata. Can we rename this bug, since it's the open one? Or reopen that one? As another poster mentioned, 2.1 is going to cause a flood of people to ask "how can I preserve my old workspace", so I suggest that #3 may be important enough to do right away.
See also bug 32147.
*** Bug 34233 has been marked as a duplicate of this bug. ***
*** Bug 36763 has been marked as a duplicate of this bug. ***
You should use the proper location of application-data for the OS (the location also used by nativerunning Eclipse as default. That would be "%HOME%\Application Data\Eclipse" for Win NT/2K/XP and "~/Library/Application Support/Eclipse" for Mac OS X. A generic unix would use "~/.eclipse" instead.
The Mac standards suggest that Application Support is used to store application-specific data. In any case, the application directory should contain the name of the application, and not just something abstract such as 'workspace' -- though there's nothing to stop (for example) .../Eclipse/workspace The following describes the layout of the Mac OS X file system and describes the purpose of the ~/ Library/Application Support: http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Concepts/ LibraryDirectory.html Specifically: "[Application Support] Contains nondata items such as third-party plug-ins, helper applications, templates, and additional resources that can be used by the application but are not required for it to operate. By convention, items should be put in a subdirectory named after the application. For example, third-party resources for the application MyApp would go in Application Support/MyApp/. Note that required resources should go in the application package itself." Following these ideas, the name should probably be rooted at ~/Application Support/Eclipse/ though if necessary, the data could be in ~/Application Support/Eclipse/.metadata IMHO I don't think the '.' prefix is desirable on a Mac platform; it's only really to stop it being seen in a home directory on other Unix platforms when the default would be ~/.eclipse or ~/.metadata. Instead, I'd prefer to see it in ~/Application Support/Eclipse/metadata so that I could browse to it easily in the Finder.
This is a Unix bug.
FYI Mac OS X has a unix kernel; specifically, Darwin, which is based on Free BSD. The OS is set to 'Unix All' which therefore should include Mac OS X :-)
Minor correction: when you said ~/Application Support, I think you meant ~/Library/Application Support, right?
Yes, it of course should be ~/Library/Application Support/Eclipse -- I got it right above, then just forgot the Library the second time around ...
> "[Application Support] Contains nondata items such as third-party plug-ins, > helper applications, templates Note "nondata". metadata is data, so should exactly *not* be stored in Mac's Application Support folder, per the rules you cited.
Actually, by 'non-data' it means not objects created by the application. So for example, configuration files and preferences are stored there, as opposed to documents created by those applications. In essence, this fits the description of metadata quite nicely; specifically, the objects created by Eclipse (Java documents, XML documents etc.) shouldn't live in ~/Library/Application Support/Eclipse, but but the configuration, preferences, and fast cache data should. Unless you term 'non-data' to mean 'no files at all', in which case it would be a suspiciously empty folder :-) That's the interpretation of the folder from the contents of my folder, in any case. And the lack of Eclipse's metadata shouldn't stop the app from working, as is also highlighted in that comment.
This bug should higlight more importance that the default place for the .metadata does not have to be the same as the default location for storing Eclipse projects. For example, under Mac OS X, the .metadata may be stored in ~/Library/Application Support/Eclipse, whereas the project location would be more likely to live in somewhere like ~/Documents/Eclipse Bug 11992 described the project location issue, which was closed as a duplicate (though it isn't strictly a duplicate, but very related). The new 'ask where the location lives' in M8 (on Mac OS X) is good, but it still doesn't default to a per- user directory.
Johan (or another empowered user) -- can you change the title of this bug to be 'Metadata and default project location should be stored in a per-user directory' instead, which would more accurately reflect the comments in this bug?
*** Bug 57350 has been marked as a duplicate of this bug. ***
Note that even though the new M9+ installs allow the workspace to be configured to a different location via a dialog (if the -data isn't passed on the command line), it still writes the configuration for this in the same install location of the Eclipse product. Thus, even though it's now possible to store the workspace in a per-user directory, two users on the same machine *still* can't use the same install of Eclipse, since otherwise running it a 2nd time will default to using the 1st user's location (assuming the users will check 'Use this as the default and do not ask again'. Ideally this configuration should by preference store it in a per-user directory instead of the global where-the-app-is-installed location. On other Unix systems, it still may not be possible to write into the directory where the app is stored (e.g. on a university standard location/shared drive).
*** Bug 67558 has been marked as a duplicate of this bug. ***
Obsolete bug...This was fixed in 3.0.
This issue hasn't been fixed in 3.0. On a default install on windows, it still dumps the workspace (and associated .metadata) in the program install location, and not on a per-user location. The 'configuration' file hack doesn't resolve this either; because the configuration is still written into the program install location. You will note that owing to various other bugs that were closed 'duplicates' of this bug (specifically, that you may not be able to write into the program install location for ANY types of files, commented in #27), this bug is alive, well, and most definitely not fixed.
I believe it tries to put the workspace in the install area and if it can't then it puts it in the user's home directory. Also Eclipse 3.0 now contains the workspace chooser dialog which prompts the user for a location for thier workspace.
Regardless of where it finally ends up putting the workspace (and the enclosed metadata), it writes a 'configuration' entry into the product install area to point to the workspace. Thus, when two users on a multi-user operating system run Eclipse, they still end up sharing the configuration entry and thus the same workspace. So even though the workspace may be somewhere else (as picked by the startup chooser), it still writes into the install directory and thus limits Eclipse's use on multi-user systems.
The model for multiple users sharing the same workspace is that every user has its own configuration location, so this should not be an issue. This can be achieved by not giving users priviledge to write to the Eclipse install, or by explicitly choosing a private configuration area (-configuration @user.home, for instance), which is more error prone.
It should not be the case that you are relying on a read-only property of the install location to default elsewhere. The policy should always be to default into a user-specific area, and not into the program's install location. For example, on Macs, the application is put into /Appications, which normally has permissions to allow the group to write. If I am an administrator, I can write configuration files into that application, but if another administrator runs Eclipse, there will be a clash. It is also worth observing that comments #2, #4 discuss that trashing the application's install directory shouldn't end up trashing the workspace as well. And, as raised in #12, the title of this bug is too specific -- it's ANY files generated by Eclipse that should live under the user's home directory, and not just metadata. Bug 11992 clearly phrased that it should be all data, not just metadata, that lives in the directory, and depsite being closed as a 'duplicate' in #5, the title of this bug did not get updated to incorporate more general workspace-and-other-config files as well (even though this was highlighted six months ago in #25) Lastly, sometimes Eclipse users just don't have (easy) access to the command-line parameters. Clicking on an icon in Windows (or on Macs) will just launch the app; either with no arguments or predefined arguments. Whatever the case; the default install of Eclipse should NOT look for the program install location as its first choice. Frankly, it shouldn't ever be chosen. Does Microsoft Word ask you to save documents in Program Files? Does IE download files into Windows\system32? Why on Earth should Eclipse be different and decide that the program install location is a sensible place to store data???
Just a clarification: the workspace suggested default location is *not* the Eclipse install, but the current working directory. However, clicking on the eclipse launcher, which seems is what many people do, will launch Eclipse having the install location as the current dir.
Re: comment 32 - comment 27 - this is a different issue. I opened bug 77911 to address that problem. Also note that having something $HOME/.eclipse/workspace as the base location for you workspace is as simple as having the following in your config.ini: osgi.instance.area.default=@user.home/.eclipse/workspace This would change the default workspace suggested to the user by the first time Eclipse runs. Making this part of the config.ini shipped with Eclipse is another thing. It may cause confusion for people used to the current model (entry-level users using Windows). And it would require another path segment to safely support product-specific workspaces (as we already support for the configuration location). The good thing is that the workspace chooser has made this issue less critical. Regardless what way we decide things should be, it will always be just a suggestion. The final choice is up to the user.
Closing again. All the required support is there in Eclipse 3.0. It won't be made the default setting since the most common usage is a non-shared install. Making the install directory read-only will change the default to a user-specific location. As mentioned in bug 77911, we could explore making configuration of shared installation easier.
