Community
Participate
Working Groups
Eclipse currently requires the root of the project tree to contain the .project file. This is embarrassing in a group where people are using different IDEs and *their* IDE doesn't require this. Other people get annoyed at you for not keeping IDE-specific files in IDE-specific subdirectories. It would be nice to somehow have the .project file someplace else, e.g. in a subdirectory, something like: project_root ide eclipse .project and then I imagine the .project file could have an entry that's something like <project_root>../..</project_root>. Of course this, is sort of a major change in how Eclipse thinks of projects... (I tried searching for other bugs that mention this, only found a similar comment here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973#c6 )
*** This bug has been marked as a duplicate of 76695 ***
*** Bug 93538 has been marked as a duplicate of this bug. ***
I don't think this is a duplicate of 76695. 76695 is asking for consolidation of all .project-type files into one directory, which would also be very nice. But this request is for the .project file to not have to live at the root of the logical file system directory of the "project root". 76695 is marked as won't fix because "There is no way we can control where plugins put their project-specific metadata. The ProjectScope in the preference API is the prescribed place to put metadata, which would result in all metadata being stored in the single .settings folder. Whether plugins adopt this mechanism is up to them." But that has nothing to do with this particular request. The platform owns the .project file and its location. In theory the .project file could live anywhere and just refer to the root project directory. This is a problem for us because many users have projects whose logical root directory is the same. In the current model they can't have two such projects in Eclipse. The other mention that these files get messy when dealing with version control is another issue that affects us, but not as important is this one IMO. Anyway, I'm sure this type of change isn't something to take lightly, but thought we could open it back up for discussion.
Note: I opened bug 93538 to try to get some clarification to comment #3 and the original request. Here's additional comments: Can someone on the eclipse platform please review this bug and suggest why having the ability to change the project root in the .project file is an invalid request? Or possibly suggest a workaround to this problem? We are running into problems where it's not uncommon for a source base to contain projects that need the same source root for (literally) hundreds or projects. This forces users to continually close projects and re-create them becuase you cannot have two projects with the same root. Why not just allow putting the the .project files under the workspace? e.g. Here you have two projects both of which have a root of \myproj\src\ \myproj\src\prj1\ \myproj\src\prj2\ Why not just allow the .project to be under the workspace? e.g. c:\workspace\prj1\.project c:\workspace\prj2\.project Thanks, Tim
Sorry, bug referred to in comment 4 is incorrect. It's bug 181225.
*** Bug 181225 has been marked as a duplicate of this bug. ***
See bug 181225 for response to comments. Please add further comments here and I will try to respond.
Hi John - Thanks for the reply. You said: <JA> I.e., leave the project location in the workspace, which will cause the .project and other Eclipse metadata files to be written there. Then link in the source folder that contains the code. </JA> We tried doing exactly this (linking folders), however it creates far more problems than it solves. For one, version control doesn't work at all. What we're asking for is for the .project file to be able to point to the root folder of the project and not have it be implicitly determined like it is now. I could probably do an analysis and track down all the problems linked resources create if it would help, but I can say for now that it's not an option. It may help to know that are dealing with C++ projects and are using CDT 4.0. Could I get some input as to why it's not possible to redefine the project root from within the .project file and have it point anywhere you want?
Think through how that would work with respect to source control. Where is the .project file stored in the repository? How do we figure out where to store the .project when you check the project out of the repository?
I've just returned from vacation so this information isn't as fresh in my head as it could be, but here's what I believe the situation is. People were asking for a more flexible project location to support cases where multiple projects share the same logicial root directory in the file system. The platform's response to this was linked resources. This addresses the original issue, but in practice caused other problems that could not be worked around. Our first product based on Eclipse had two options for creating a project from existing source. One was to copy everything into the workspace which is where Eclipse is most happy. This works grand in most cases, but breaks most version control systems and makes people uneasy having to make copies of their code. The second was to create the project in the workspace, but link to files/folders under the logicial root directory in the file system. Note that we weren't linking to the root directory itself because it was a little strange looking having that extra level in there, e.g. a project name foo rooted at C:\foo would like like foo\foo in the navigator rather than just foo. This option proved to be worse though because version control doesn't work at all with linked resources. The team stuff doesn't work on anything outside of the workspace. :( There were other problems as well like not acting on resources themselves but rather on the links, e.g. deleting foo.cpp only deletes the link but it's still in the fiel system. We experimented with various option of linking every resource or just root folders. In both cases we ran into unexpectyed behavior like not acting on the file/folder itself but only the link, or that creating new files/folders would create them in the workspace where the project is but not where all of the other sources are located in the file system. Basically we had a very unfriendly project model. For our next product we spent much more time investigating a better way to create projects for existing source. We had to rule out any linked resources due to the problems mentioned above. As far as we could tell that left us with one option - create the .project file at the logical root directory in the file system. This gives the user what he wants in the navigator views under his project, he's always acting on those resources (not links), and version control works fine. The only problem we've found with this approach is that you can't have more than one project at that logicial root. Unfortunately this is a big problem for a lot of users. I don't know what the best solution is here, but we're certainly willing to work with the platform team on figuring it out. The two things that jump to mind (without putting much thought into it) are a) allow the project file name to be anything.project, rather than just .project. that way they could all live at the same root as long as they have unique names. b) have another property in the .project file which specifies the root directory - the one that the navigator view starts at when expanding a project. this could maybe be absolute or relative to the project file itself, e.g. <location>C:\foo\</location> or <location>../foo/</location>. Perhaps when the location element is not specified it just defaults to the directory containing the .project file which would provide backwards compatibility. That's about all I have for now. As Tim mentioned, there were other problems with linked resources that I can't recall right now but can dig around and find if necessary. Let me know if there is another way to do what we're trying to do without changing the platform. If not, can we discuss the two options? Thanks, Warren
John, in response to comment #9, the .project is usually thrown away. So for many of our users the workspace is not where they do their work from, their sources exist outside the workspace and don't ever want the .project (or other IDE settings files) to be part of their repository. These users keep their projects in their own custom makefile format and just have us regenerate the .project file for them and really throw away their eclipse workspaces frequently. However, if users did want to keep their .project and related files we could put them in a directory that was not the implicit root (as is now) but somewhere relative to the root in a unique project folder.
John, We're getting a lot of heat on this issue. It is really important for us to get a solution to this for Eclipse 3.3 or 3.3.1. We're willing to do the work and add a patch, but need some confirmation from the platform team. Can you please comment on my proposed solutions (a & b)? a seems to be the easiest solution but I'm not sure what the ramifications are. I'd like someone from the platform team to sign off on a design before I do anything. Thanks, Warren
Reopening as requested since this is not a duplicate.
I think I'm still not understanding the use case. If you have two projects at a common root, why do you even have two projects rather than just one? Multiple projects at a common root would cause that entire file system tree to be duplicated in the workspace tree. What's the reason for not just having a single project? One possible solution is to store the .project file elsewhere, in the workspace metadata directory. This is what we did in Eclipse 1.0, which did not have .project files. The main problem with this is that projects were not self-describing - you couldn't zip up, or store in a repository, the project contents and be able to recreate the project in a different workspace, because information such as builders, natures, etc, was lost. For reference, here is the design document that described creating the .project file in the first place: http://www.eclipse.org/eclipse/platform-core/documents/rfc/0006/index.html The other major problem I see is that there is now a proliferation of metadata files in the project area. Project preferences are stored in .settings directory, and various other components store metadata such as JDT .classpath files in the project root. Do you have no other metadata files of concern other than .project, or are you looking to solve a more pervasive problem? A fix in 3.3 is highly unlikely - the development freeze is May 4th, which gives us about a week and a half of real development before the milestone fix/test pass. I'm actually not convinced this can be changed at all in a backward compatible way. The .project location is spelled out in our API, and there are other components that rely on this location that would be broken by such a change. The API of IProjectDescription.DESCRIPTION_FILE_NAME is: * Constant that denotes the name of the project description file (value * <code>".project"</code>). * The handle of a project's description file is * <code>project.getFile(DESCRIPTION_FILE_NAME)</code>. * The project description file is located in the root of the project's content area. I'd be interested in pushing on whether we can satisfy your user's workflows in another way, but as I said I don't think I understand exactly what you're trying to do...
(In reply to comment #14) Hi John, thanks for the repsonse. See my comments below. > I think I'm still not understanding the use case. If you have two projects at a > common root, why do you even have two projects rather than just one? Multiple > projects at a common root would cause that entire file system tree to be > duplicated in the workspace tree. What's the reason for not just having a > single project? Because they are naturally two (or more) different projects. You would want to build them separately and have them somewhat isolated from each other. A very simplistic way to look at this is you have two .exe's that share some common code. They are completely different exe's and have their own makefiles or what have you to build them. The directory structure might look something like this: C:\MyProjects\exe1\... C:\MyProjects\exe2\... C:\MyProjects\CommonCode\... The natural project root for both exe's is C:\MyProjects\, which would mean expanding the project in the navigator, you get to see all related source code (and possibly some unrelated source code). You could say just make C:\MyProjects\exe1\ and C:\MyProjects\exe2\ the project roots, but then you're not able to work with the common source. These exe's can be built differently and need to have their own project properties. I don't see how they could be combined into a single Eclipse project. > One possible solution is to store the .project file elsewhere, in the workspace > metadata directory. This is what we did in Eclipse 1.0, which did not have > .project files. The main problem with this is that projects were not > self-describing - you couldn't zip up, or store in a repository, the project > contents and be able to recreate the project in a different workspace, because > information such as builders, natures, etc, was lost. For reference, here is > the design document that described creating the .project file in the first > place: > http://www.eclipse.org/eclipse/platform-core/documents/rfc/0006/index.html > The other major problem I see is that there is now a proliferation of metadata > files in the project area. Project preferences are stored in .settings > directory, and various other components store metadata such as JDT .classpath > files in the project root. Do you have no other metadata files of concern other > than .project, or are you looking to solve a more pervasive problem? There are two types of users, those that want to check these project files into version control, and those that don't. Those that do want them alongside their other files under version control. Those that don't want these files considered "temp" files and not stored in the file system with their files under version control. For us there is the .project and .cdtproject files, and the .settings folder which can contain any number of files. My understanding (more of an assumption) is that these are relative to the .project file location and would move if the .project file were moved. Here's a look at my example with the two potential solutions: Solution a: allow .project file to have a prefix C:\MyProjects\ could be the root for both projects, with two project files in that directory named exe1.project and exe2.project. Other files would have to follow suit, e.g. exe1.cdtproject, exe1.settings, etc.. This could be problematic. Solution b: have an optional <rootLocation> project attribute: When blank, the project root is the directory containing the .project file. I think this lends to backwards compatibility. We could have C:\MyProjects\exe1\.project, which has something like this in the .project file: <rootLocation>C:\MyProjects\</rootLocation> or <rootLocation>./../</rootLocation> > A fix in 3.3 is highly unlikely - the development freeze is May 4th, which > gives us about a week and a half of real development before the milestone > fix/test pass. I'm actually not convinced this can be changed at all in a > backward compatible way. The .project location is spelled out in our API, and > there are other components that rely on this location that would be broken by > such a change. The API of IProjectDescription.DESCRIPTION_FILE_NAME is: > * Constant that denotes the name of the project description file (value > * <code>".project"</code>). > * The handle of a project's description file is > * <code>project.getFile(DESCRIPTION_FILE_NAME)</code>. > * The project description file is located in the root of the project's content > area. > I'd be interested in pushing on whether we can satisfy your user's workflows in > another way, but as I said I don't think I understand exactly what you're > trying to do... I appreciate the problem, and if we can find another way to do it then that's fine. But we haven't come up with any other solution yet. Any other suggestions? Thanks, Warren
Just wondering if anyone has any new thoughts on this?
I posted a summary of the issue at: http://nokiacarbideoneclipse.blogspot.com/2007/05/structuring-c-projects-in-eclipse_07.html There are a couple interesting comments but no new ideas we had overlooked.
See http://wiki.eclipse.org/CDT:Flexible_Project_Structure for more on this issue and how it affects C/C++ development in Eclipse. The CDT team is trying to figure out a way to make project contents more flexible. Any platform team advice would be much appreciated.
The discussion is a bit hard to follow, but it seems like this bug report has eveolved from a simple request to move the .project file out of the project root, into a more complex issue around supporting multiple projects under the same root. While I see the relationship between those two requests, can we either update the summary/description of this bug of open a separate one for the "multiple projects under same root" issue? Personally, I opt for the latter, because there is a simpler and more common request to just move the .project file.
So if this bug remains as its current summary and initial description... If I understand correctly, the objection to making the .project location be configurable is because we need to maintain the self-describing nature of Eclipse projects. If I'm correct about that, then it seems like we could have the best of both worlds be adopting the "convention over configuration" philosophy. For example, an algorithm something like this: * Look for .project at the project root. If found, use it and stop. * Look for a file named .project in subdirectory of the project with a well-known name, such as .eclipse/. If found, use it and stop. * Look for a file named .project in any immediate child directory of the project root. If found, use it and stop. I think the intention is clear. The algorithm could be as "intelligent" (or "inquisitive" if you prefer) as we want; I'm just suggesting that it be somewhat more intelligent and flexible than the current ".project MUST be at the project root."
(In reply to comment #10) > > a) allow the project file name to be anything.project, rather than just > .project. that way they could all live at the same root as long as they have > unique names. As Warren has already said, I think a lot of the problems discussed in this bug go away if we just stop calling the file ".project" If instead the project file has a unique name, e.g. "myproject.project", then it's easy to have multiple project files coexisting in the same directory tree. Then the semantics become "open this specific .project file as a project" rather than "open this directory as a project and look for a .project file in it." As a fallback for backwards compatibility, opening ".project" with no prefix will assume the project root is the directory in which the .project file lives. In order for this to be usable though, we'd have to couple this with the other flexible resource/workspace changes being discussed for e4. There is not a whole lot of sense having two *.project files in the same directory if they are still forced to include all the same content from all the child folders due to the current project/resource semantics. Granted, each project could have different metadata associated with them and still have the same resource tree, but the main use case that people desire is to have the projects viewing different subsets of the files on disk.
I'd love to be able to provide a custom extension for defining the project description store ... I work in an environment where there are mixed IDEs, and I can fully generate what is in the .project file on-the-fly from other existing build-system metadata. It would be very useful to be able to register my own IProjectDescriptionStore that could be in-memory-only and build on-the-fly. In my case, I don't need the complexity of multiple projects in one folder, I would just like an abstraction on top of the storage mechanism itself.
In comment #14, John wrote: > I'm actually not convinced this can be changed at all in a > backward compatible way. The .project location is spelled out in our API, and > there are other components that rely on this location that would be broken by > such a change. The API of IProjectDescription.DESCRIPTION_FILE_NAME is: > > * Constant that denotes the name of the project description file (value > * <code>".project"</code>). > * The handle of a project's description file is > * <code>project.getFile(DESCRIPTION_FILE_NAME)</code>. > * The project description file is located in the root of the project's content > area. John, can you comment on whether the API Javadocs you quote above will necessarily prevent the search algorithm idea that I described in comment #20 ?
Since it seems like discussion on this bug has died down, I'd just like to chime in and say we're also interested in having this bug fixes. We don't have multiple projects with the same root, but we do want to cleanly interoperate with non-Eclipse environments, where ".project" may be a filename that's already in use for some other non-Eclipse purpose. (In reply to comment #21) > Then the semantics become "open this specific .project file as a project" > rather than "open this directory as a project and look for a .project file in > it." Personally, I really like this solution, though I can imagine it would require a lot of breaking changes to existing Eclipse API.
We also have a not so uncommen case where we desperately want to move the .project file somewhere else: it is 1 project where mutliple teams work on and some have different programming languages! So the project has different subdirectories like Java/, vb6/, net/ and also common subdirectories like images/, resources/, configs/, etc. So, the Java developers need to define their Java prjects in the main project directory (because they don't just work with the Java/ subdirectory)!. For this reason, all teams check in/out the main project. So far, so good. Now comes the problem: for specific files, a different SVN client is used to check in. Unfortunately, with major SVN version changes, those clients get incompatible! E.g. SQL Source Control is still SVN 1.7 but TportoiseSVN is already SVN 1.8 that is (client side) incompatible. Until this update, all teams just did a check out/update on the main project root directory. This doesn't work anymore since the different SVN clients are incompatible (and there are no new versions for each SVN client to upgrade all to SVN 1.8!). The short minded solution was, to move all Java required files to subdirectory Java/ and only check out this directory for the Java developers - in this case, movinf .project to Java/ would have worked - but this would involve to recreate the Java projects to use a new project directory and therefore all other resources would get out of scope for the Java project! If we could move .project to a subdirectory (e.g. java/Eclipse/), we could still use the main directroy as the Java project directory but only check in the java related files with the single Java/ subdirectory. In the current case we have to update/check out the files in java/ and in addition the Eclipse metafiles (.project, .classpath) in the projects main directory. (Just to repeat: we can' just update/check out the main project directory anymore as there exist subdirectories that have a different SVN version.) I hope I made things clear ... being able to move the .project (and .classpath, etc.) files to a configurable directory would help very much!
I'm very surprised this has not been addressed in the 10 years it has been vocalized about. Is there a reason it has been blocked out? It is very annoying having my IDE files exist in the same directory as a project, especially when that project is a version controlled with other users who can accidentally commit their own .project/.settings/.buildpath files into version control and then I have to be sure not to accidentally import those files over mine. It seems very odd to force IDE files to exist in a project folder. Not to mention the fact that those are very generic names for files that could be wanted to be used be an actual project. It's not like they are even contained in a ".eclipse" sub dir like how .git and .svn are... Can this please be fixed? thanks! :)
Hi, we are also facing the need for the .project file not to be at the project root. Has any progress been made here? Is there a known workaround? Best regards Peter
So let's keep pushing and see if we reach the 12th anniversary... Another use case which should be simple and gets absurdly difficult thanks to the forced .project file: I have machine A with a source folder, and virtual machine V which runs a building environment. I want to use the source folder as an Eclipse project BOTH in machine A and in the VM V, editing and building and running in both of them. I need the full Eclipse GUI in both (there are plugins that only work in each machine). I need to "share" the source folder because I want to be iterating quickly between builds and results in both machine A and VM V. I might accept closing one Eclipse, or one project, while the other is running. This should be easy, right? I don't want any communication between Eclipses. Just create separate workspaces in each Eclipse, a project in each workspace, and have each project refer to the source folder. WRONG, the source folder contains the damned .project file (and the .settings folder), so there is no way to do this simple "sharing". Worse, the settings get thrashed without any warning. Alternatives: -- use linked folders: Eclipse integration with versioning systems stops working, and I bet it won't be the only roadblock; indexing seems to be broken. -- PTP synchronized project: ... O-M-G. Even if the monstrosity works, I guess I can say goodbye to the idea of "quickly iterating".
Celebrating this tickets 13th anniversary, I'm hoping we see this issue resolved. Our team use IDE as our primary development IDE. We would love to have the eclipse projects IDE related metadata abstracted away from our source repository project code. In our local development environments we each have our local repository folder separate to our workspace. i.e. ~/workspace/neon and ~/repos/same-repo We symbolically link this local repo to one or more workspaces eg. ~/workspace/neon/some-repo -> ~/repos/same-repo ~/workspace/oxygen/some-repo -> ~/repos/same-repo Use case 1: As a user I want to be able to easily test a new version of eclipse with minimal impact on our daily eclipse IDE workspace. Allowing us to revert back to our daily eclipse IDE quick. Use case 2: As a user I want to create a new workspace and commit code against the same local repo as my daily eclipse IDE does. Project metadata should not be overwritten when switching between the two. Use case 3: As a user, when my workspace metadata has problems and needs to be recreated the action of recreating the workspace and re-importing project code from our local repo should not affect or alter workspaces of other eclipse IDEs. i.e. recreating & reimporting ~/workspace/neon/ should not affect ~/workspace/oxygen/ The only way to satisfy these use cases is if each individual projects metadata is not stored in the root of that project.
Why do you link the checked out folder at all? You can simply create a new workspace, import the projects from your SVN locaten. Now you can - copy workspaces - use with different eclipse versions - save workspace state in a zipped folder and so on. The "workspace part" has nothing to do with the .project
If there is a workaround it would deserve a longer and thorough description. I searched without success how 2 people can use distincts Eclipse versions on the same project. Does not seem that easy. For example, see: https://wiki.eclipse.org/CDT:Flexible_Project_Structure
As this thread is very long (and old), tried to understand if the original request had been solved already, seems it didn't - am I wrong? In a nutshell, I want all eclipse files to be under eclipse-workspace folder with sub-folder per project, and not under the source files directory (from same reasons mentioned at this thread beginning) - is it possible? if the answer is yes, so question how? Regards, Gad
I think my use-case is similar to several previous commenters but I would prefer to keep tool configs outside of the workspace entirely. In my case, I don't want to pollute a pristine local workspace with files that are not necessarily shared with others in the development. If they're outside a project's shared source tree then other options become available for managing them, including with possibly different versions of them, that aren't available now.
The VS Code Java, which is back-ended by Eclipse JDT.LS also has this request. Actually this is the most top issue complained by users, see: https://github.com/redhat-developer/vscode-java/issues/618. After taking a look at the eclipse.platform.resources project, I found that maybe the class FileStore is the key for this problem since it provides input and output streams of the real file. One approach that's in my mind is to make the getStore() and some related methods contributable from other client which depends on the Resource plugin. The default implementation will still be the same as it is. But the client can inject a customized implementation dealing with the FileStore things. Then it's the client's choice to put these generated files wherever it wants. Especially since different language may have different generated files, the client can handle these special files by their own. Hope someone working on this project can share any comments on this thought. I'm willing to contribute a PR for this proposal if the it looks fine. BR, Sheng
(In reply to Sheng Chen from comment #34) > > One approach that's in my mind is to make the getStore() and some related > methods contributable from other client which depends on the Resource > plugin. It could be a solution _if_ it will not break alternative file system implementations available via "org.eclipse.core.filesystem.filesystems" extension point.
(In reply to Sheng Chen from comment #34) > The VS Code Java, which is back-ended by Eclipse JDT.LS also has this > request. "This" request varies from comment to comment, unfortunately. Please explain in details what is "your" request about, *before* proposing a solution :-) May be better to start a new bug to get rid of all the history and concentrate on a *single* enhancement you envision.
(In reply to Sheng Chen from comment #34) > After taking a look at the eclipse.platform.resources project, I found that > maybe the class FileStore is the key for this problem since it provides > input and output streams of the real file. I'm not sure it's the right approach. If I understand correctly, you're thinking about hacking FileStore so it intentionally returns "wrong" content for a given path (by wrong I mean returning a non-empty content for a non-existing file). I don't think this is the purpose of FileStore which is expected to properly map the underlying file resources. What you may want to look at is the various usage of IProjectDescription.DESCRIPTION_FILE_NAME. You'll find some in Project, or FileSystemResourceManager.internalWrite(). I imagine some preliminary refactoring would be to extract a "FileStore getProjectDescriptionFileStore()" method from Project, that would be reuse everywhere it makes sense when reading or writing the file. By using a FileStore here, and not a IFile, it allows to put the file outside of the workspace, for example in a metadata location. Once this method is extracted, it would be easier to implement alternative strategies to load it, such as -if .project doesn't exist in folder and some magic setting is set- failing back to some known metadata location.
Thank you all for the quick response. I filed a new issue according to Andrey Loskutov's suggestion. https://bugs.eclipse.org/bugs/show_bug.cgi?id=576013 let's discuss there. :)
