What of Eclipse project .metadata can I safely ignore in Git/Mercurial?
Asked Answered
T

5

44

We have the code for an Eclipse RCP application in an Eclipse workspace containing multiple Java projects. We are using Mercurial with a simple .hgignore just *.class (but the same issue would pertain to Git).

Even a small change to the code can result in many of the files in .metadata getting changed.

I'd like to exclude some or all of the .metadata from version control. If we exclude it completely, the workspace is lost.

Does anyone know what we can safely exclude? Alternatively, how can we recreate it if we pull the code down to a fresh computer?

Thickknee answered 25/11, 2010 at 15:27 Comment(2)
Am i given to understand that you are storing the whole Eclipse workspace in a single Mercurial repository? Have you considered storing each project in a repository, then grouping them as subrepositories of an umbrella repository so you can version them together (although i don't know if Eclipse has any support for that)?Hydromagnetics
It's a plugin-based product, and the separate projects each define plugin. All are needed together or the overall product. So the individual projects are just part of the whole, which is why we wish to store the whole Eclipse workspace in a single repository.Thickknee
H
16

The files i'm personally aware of are:

  • version.ini (not very exciting)
  • .plugins/org.eclipse.jdt.core/variablesAndContainers.dat (classpath variables)
  • .plugins/org.eclipse.core.resources/.projects/*/.location (projects in the workspace)

Somewhere, i have an Eclipse workspace used for testing some Eclipse-related tools that is pretty severely cut down, but works. I'll see if i can dig it out.

Hydromagnetics answered 25/11, 2010 at 15:42 Comment(2)
Thanks! That just about worked. I also had to keep .metadata\.plugins\org.eclipse.core.resources\.root and .safetable.Thickknee
I had to add .metadata/.plugins/org.eclipse.wst.jsdt.core/variablesAndContainers.dat as well.Stpierre
B
54

GitHub is maintaining a community "gitignore" project that catalogs suggested filespecs for ignores for various platforms, editors and languages: https://github.com/github/gitignore

Eclipse ignores are here: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

(If there are other filespecs that they should know about, let them know!)

Beetle answered 25/11, 2010 at 15:51 Comment(2)
An excellent project! That particular ignore list has two issues, though: one is that it ignores some things you'd definitely want to check in, like .classpath, and the other is that it's about things inside project directories, whereas the OP wants to check in a whole workspace. If you applied that list to a workspace, it would (i think) ignore the entire .metadata directory, which would lose some quite important things, like the project .location files. Really, though, the problem here is Eclipse, which mixes up authoritative and derived files in a very unhelpful way.Hydromagnetics
That github file ignores the entire .metadata folder. OP wants to save parts of the .metadata folder so they can share the workspace, so this doesn't answer the question.Twigg
S
39

Metadata and Workspace

I would never share the .metadata folder. In fact unless you have a particular reason I would not even share the workspace folder but instead share each project separately with git. That way the .metadata folder will always be in the parent folder of your git repository and you dont have to think about whether you need to ignore it anyway:

|-- workspace/
|  \-- .metadata/
|  |-- yourProjectOne/
|  |  \-- .git/
|  |  |-- .project
|  |  |-- src/
|  |  |-- ...
|  |-- yourProjectTwo/
|  |  \-- .git/
|  |  |-- .project/
|  |  |-- src/
|  |  |-- ...

Project Specific

You should probably always share the .project file and never .settings/ files. The .classpath may depend on your environment but I would not suggest to share it either, because it can cause conflicts (for example if one user uses openjdk and the other uses sun-jdk. The .settings contains preferences and settings for eclipse and changes a lot, thus it should not be shared. If you properly import the project after you cloned it from git then you will also not have any problems.

The eclipse documentation states the following about the .project file:

The purpose of this file is to make the project self-describing, so that a project that is zipped up or released to a server can be correctly recreated in another workspace.

and:

If a new project is created at a location that contains an existing project description file, the contents of that description file will be honoured as the project description. One exception is that the project name in the file will be ignored if it does not match the name of the project being created. If the description file on disk is invalid, the project creation will fail.

I also suggest to use Maven as this will save you a lot of problems with the dependency management and .classpath

Maven

The main difference with a Maven project is that you can import the project as Maven->"Existing Maven Projects" and thus only need to share the pom.xml and .project file in git. Eclipse will then create the .classpath, .settings/ files for you automatically. Thus obviously you dont need to share them. If something changes in pom.xml you simply run Maven->"Update project configuration" and Maven->"Update dependencies".

Without Maven

You should share the .project file and not the .settings/ folder. You can considere to share .classpath but it may lead to conflicts as explained above. I would suggest not to share it either. Use the method below to import the project:

After you have cloned the git repository you can simply use Import->"Existing Project from Workspace" eclipse will honor the .project file but recreates the .classpath and .settings/ files. After the import you will need to configure the classpath by hand from Eclipse (and everytime your team wants to use another library).

If you do not share the .project file, then it is not possible to import the project with Eclipse. You will need to create a new project with the project wizard first, and then you can choose import "General->File System", this will copy all the files into your workspace. This is probably not what you want, because it means that you cannot clone the git repository into the workspace, you must clone it somewhere else and then import it from there. Therefore you should always share the .project file.

Please leave a commend if you have suggestions to this explanation or if you dont agree with it. I hope this helps the one or other.

Screen answered 3/12, 2011 at 16:4 Comment(2)
With maven and m2e, is it even necessary to share the .project?Biographer
Very useful instruction. I was confused why all gitignore file include .project. But after your instruction, I decide to share .project.Razee
H
16

The files i'm personally aware of are:

  • version.ini (not very exciting)
  • .plugins/org.eclipse.jdt.core/variablesAndContainers.dat (classpath variables)
  • .plugins/org.eclipse.core.resources/.projects/*/.location (projects in the workspace)

Somewhere, i have an Eclipse workspace used for testing some Eclipse-related tools that is pretty severely cut down, but works. I'll see if i can dig it out.

Hydromagnetics answered 25/11, 2010 at 15:42 Comment(2)
Thanks! That just about worked. I also had to keep .metadata\.plugins\org.eclipse.core.resources\.root and .safetable.Thickknee
I had to add .metadata/.plugins/org.eclipse.wst.jsdt.core/variablesAndContainers.dat as well.Stpierre
G
4

The workspace metadata really shouldn't be kept in source control. The basic workspace configuration can be shared via a team project set.

Gertrudegertrudis answered 25/11, 2010 at 15:32 Comment(5)
Thank you -- looks promising. I'll try that out.Thickknee
A project set file includes what projects should be checked out, and from where, but nothing else. Not that i'm disagreeing with you - i think the most prudent way of working is to check in code and per-project metadata, and leave the workspaces under local control - but if the OP insists on sharing workspace configuration, he'll probably need more than a PSF.Hydromagnetics
Tom is correct; that didn't work for me. The PSF contains references to (a mis-configured and non-existent) CVS repository, to which I cannot connect, of course.Thickknee
Your link is deadTwigg
@MichaelBorgwardt " Topic not found The topic that you have requested is not available. The link may be wrong, or you may not have the corresponding product feature installed. This online help only includes documentation for features that are installed."Twigg
P
4

I routinely keep .project and .classpath, not only are they safe for git but useful.

.class and .settings are in my gitignore. Those are generated and person specific respectively.

Paramnesia answered 25/11, 2010 at 15:51 Comment(2)
It seems you are right with this statement, but I wonder why the github eclipse ignore file still contains .project and .classpathScreen
The github eclipse ignore doesn't contain .project (as of now, at least), only .cproject.Seidel

© 2022 - 2024 — McMap. All rights reserved.