Menu
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?
960
The . metadata folder is an area where Eclipse plug-ins can save any information they want to save. This will include things like your preference settings, information about the contents of projects and the indices the Java plug-in uses to find classes and methods quickly.
Click on the Window menu bar option, then choose Preferences. Type “git” in the search bar, then choose that path 'Team > Git > Configuration. Click Add Entry. Enter user.name as the Key, and your GitHub username as the Value, then add another entry with user.
In Eclipse go to Window > Show View -> Other... Then select Git > Git Repositories . A view with all your Git repositories should now be visible. Right-click on the repository you want to remove and select Delete repository . Eclipse will now ask for a confirmation and give you the option to remove all repository data.
With your project open in Eclipse, right-click the project name in Project Explorer and select Team, Share Project... Select Git and select Next. Select Create... from the Configure Git Repository window and choose a folder for your local Git repo. Select Finish.
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!)
51
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.
43
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
