Community
Participate
Working Groups
Overall Eclipse makes a few questionable decisions when it comes to startup and configuration: 1) The concept of the Eclipse startup directory is overloaded with the concept of Eclipse's configuration (I believe this is also overloaded as the way multiple users can configure Eclipse differently). 2) Eclipse requires a specific project root that can never change and all project must be subordinate to that root. (Rather draconian since no other IDE's require this). 3) Eclipse configuration and project metadata are not 'in-band', explicit and easy to manipulate (e.g. relocate) as first class objects. A possible approach that gives more flexibility: - Consider the notion of an ECLIPSE_HOME global variable or registry setting so that IDE-wide configuration information can be found in one explicit and well kown location. - Consider making project metadata files explicit (in-band). Instead of hidden '.' directories bundle all the configuration/project data into a 'Projectname.project.xml' file or the like. This will make it simple for projects to be bundled (via 'tar' or 'zip') and be relocated to another location. - With the above 2 modifications Eclipse will no longer be dependent on a specific startup directory and can be started up in any directory the user see's fit. Discussion: Under most modern IDE's (Visual Studio/Netbeans, etc) project metadata is stored in explicity _visible_ files. The benefit of having the files explicit and visible is that you can copy the directory heirarchy to _any_ other location on your disk, then simply point the IDE at the main 'project file' (Filename.sln in Visual Studio .NET) and the IDE is instantly working on your project, no questions asked. Under Eclipse I cannot do the same. If I make a zip/tar of a project and move it to another location, I _must_ keep the same Eclipse project root and then explicitly do an 'import external project'. If I simply startup Eclipse in the new project directory I loose all of my confiuration settings (why?).
Project metadata IS stored in explicitly visible files in the project content area. That's what .project and .classpath are. Also, eclipse projects CAN be stored anywhere, they do NOT have to be stored under the workspace "root" location. In the new project wizard, simply specify a different location for the project in the location entry field. Using the "import existing project" wizard does not copy or move anything, it simply attaches the Eclipse project at that location to the current workspace. Finally, simply starting Eclipse in the project directory is not sufficient because Eclipse does not automatically consider all folders in the workspace location as projects. You are allowed to delete a project from the workspace, but leave the contents behind in the workspace location for future use. You have to explicitly specify which projects should exist in any particular workspace. I believe this is similar to the behaviour of other IDEs.
re: workspace 'root' != workspace Forgive me for being unclear. I'm not sure what the Eclipse term is for master- root-directory where the '.metadata' directory is stored so I used the term 'workspace root'. This is the directory where the '-data' option can be used to change it. The key point is that the '-data' directory in its currently implementation could be improved greatly by doing a little functional decomposition. As I understand it, this '-data' directory is currently overloaded to mean 'root of the eclipse workspace hierarchy' and 'per-user configuration location'. Hence if you retarget the '-data' dir to another location, you loose all of your settings. What I think might be more more flexible and more in-line with the state-of-the- art in IDE's is to split the concept of Configuration from the idea of a project 'root'. One method might be to use an environment variable ECLIPSE_HOME or the like (ECLIPSE_CONFIG?) that would be the home to parts of the '.metadata' directory as it currently stands. re: 'hidden' files Any file that doesn't show up in a default unix wildcard expansion is 'hidden'. If I can't do a standard 'cp -r dir/* newlocation' and move my project to a new location, than effectively the file has been 'hidden'. Names like '.classpath', '.project', and '.metadata' (anything with a '.' in unix) are intentionally making my life difficult everytime I want to restructure my project layout as it grows (and we all know restructuring is painful to start with - having the tools make it harder just adds to the pain). re: Why the need for a fixed 'root' for all eclipse work in the first place? The second point that I'd like to revisit is the whole notion of an 'eclipse root' directory in the first place. It appears (and maybe I'm mistaken) that Eclipse reqires a fixed location in the filesystem to be dedicated as the 'root' from which other projects can be 'attached' (either directly in the directory hierarchy or via an 'import' mechanism). This seems like an unnecessary assuption that makes adopting Eclipse in the enterprise an excercise in workarounds instead of a simple no-brainer to adopt. I'd like to use Microsoft's Visual Studio .NET (VS .NET) as my example. I'm not a huge fan of Microsoft - but I am a big fan of Anders and .NET team's work with the whole VS .NET environment. Specifically Visual Studio .NET has some good ideas about 'Solutions', config files, and ease of use (there's no harm in outdoing the competition - and basically Visual Studio .NET for C# is the competition for Eclipse in the long run). There is no concept of a single 'root' directory for VS.NET instead there are files called 'Solutions' which encompass eclipse's '.metadata' and can exist anywhere in the directory hierarchy. Open a 'Solution' file (myproject.sln) and it contains the recepie for all of the dependent 'projects', etc. Basically it's the same as restarting eclipse in a new '-data' directory that's already been setup. The main benefit of course is that a 'Solution' is a first class entity in VS.NET (just use 'Open...' from the 'File' menu) and can be located anywhere in the filesystem. This creates a very powerful and flexible way to manage multiple projects as one entity, and easily let's you swich between your project confiurations by simply loading up a new 'Solution'. I'd love to see Eclipse adopt a similar concept and do-away with the '-data' directory altogether. Right now it appears Eclipse is only able to cope with one 'solution' (aka configuration of workspaces) and this becomes tedious as the number of workspaces increases. It would be nice to have a similar concept of a 'workspace aggrigate' that allowed the scope of a development project to only include the workspaces that were relevant to the project and not have any others visible. More importantly, by removing the '-data' directory dependency from Eclipse integrating with pre-exisiting development environments becomes much simpler (or in some cases _possible_). So in short: - Add the concept of the 'ECLIPSE_HOME' environment variable for all Eclipse per-user configuration (or use the registry on Win32) - Make the '.metadata' directory a 1st class object in Eclipse instead of a hidden directory. Maybe combine all the independent info into a single .xml bundle so this can be easily copied from place to place. 'Solution.eclipse.xml' (or hopefully a better name). - Add an option at the top level eclipse 'File' menu to open this new 'Solution'. (and again, maybe someone can come up with a better name). Thanks.
Thank you for clarifying. I believe many of the problems you raise here are covered by items in our 3.0 plan. Specifically, bug 36965 deals with allowing settings and preferences to exist separately from workspaces. Bug 37681 deals with making it easier to switch between several workspaces without using "-data". I'm going to close this bug as a duplicate and reference it in those other bug reports. If there are specific items that aren't covered in those bug reports, please enter new requests for them. Please keep requests specific... rolling several unrelated issues into a single bug report makes it difficult for us to track and respond to. Thanks again for the feedback and analysis of the problem. *** This bug has been marked as a duplicate of 36965 ***
Please reopen as this is not a duplicate of 36965 and it's still a painful bug in November 2004, one year and half after it was open. I need to be able to move workspace around and have project referenced by the workspace be relative to the workspace. I need to be able to have my project data inside my workspace directory.
Please open separate bug reports for each issue that you have, as John mentioned above. Please provide details for each feature request. Thanks.
Bug still remains unresolved 1.5 years later. Reopening.
Won't fix.
