167

We recently had an issue with an Eclipse project for one of our team members. Tomcat was not deploying JARs of the application.

We eventually noticed the .classpath Eclipse file was not the same as for the team members where the project was OK. We replaced the .classpath file with one from a project that was OK and the Tomcat deploy was complete.

Just out of curiosity and to know at what to look in the future if something is wrong, what is inside the .classpath and .project files. What can I add in there, what does it all mean?

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
totalEclipse
  • 1,671
  • 2
  • 11
  • 3
  • Is the .classpath file specific to Java? This question seems mostly language-agnostic, but from [this answer](https://stackoverflow.com/questions/7186676/whats-in-an-eclipse-classpath-project-file/14080054#14080054) it sounds like it is only relevant to Java. – Casey Kuball Sep 13 '17 at 19:47
  • related, https://stackoverflow.com/questions/13960556/interpreting-eclipse-classpath-file-what-does-kind-con-and-exported-true – TT-- Feb 18 '19 at 17:23

3 Answers3

165

Eclipse is a runtime environment for plugins. Virtually everything you see in Eclipse is the result of plugins installed on Eclipse, rather than Eclipse itself.

The .project file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view. What's the project's name? what other projects in the workspace does it refer to? What are the builders that are used in order to build the project? (remember, the concept of "build" doesn't pertain specifically to Java projects, but also to other types of projects)

The .classpath file is maintained by Eclipse's JDT feature (feature = set of plugins). JDT holds multiple such "meta" files in the project (see the .settings directory inside the project); the .classpath file is just one of them. Specifically, the .classpath file contains information that the JDT feature needs in order to properly compile the project: the project's source folders (that is, what to compile); the output folders (where to compile to); and classpath entries (such as other projects in the workspace, arbitrary JAR files on the file system, and so forth).

Blindly copying such files from one machine to another may be risky. For example, if arbitrary JAR files are placed on the classpath (that is, JAR files that are located outside the workspace and are referred-to by absolute path naming), the .classpath file is rendered non-portable and must be modified in order to be portable. There are certain best practices that can be followed to guarantee .classpath file portability.

Isaac
  • 16,458
  • 5
  • 57
  • 81
  • 2
    @Isaac - Out of curiosity, in case I manage my project with `git` and `Maven`, meaning I have (for simplicity) the "root" folder of the repository (project) with a single `src` folder (holds a simple "hello world" `.java` file) and the project's `pox.xml` file - so, If I understood you correctly, there is no need (or maybe even necessarily no need) to keep the: `.project`, `.classpath` and `.settings/` files/folders as well in the `git` repository (i.e.- add them to the `.gitignore` file for example) ? – Guy Avraham Dec 11 '18 at 15:01
  • 3
    @GuyAvraham that depends on how you work with Eclipse, and specifically — how do you initialize a workspace. Do you start Eclipse on a new workspace, and then use "import existing Maven projects"? if so, then you're right — none of these files are really needed, as `m2eclipse` takes care of that for you (or, at least, that's what it's supposed to be doing). – Isaac Dec 11 '18 at 19:57
  • @Isaac - Yes, this is exactly how I use it. Thanks for the reply! – Guy Avraham Dec 11 '18 at 20:01
  • should I add these files to `.gitignore` ? – buncis Sep 19 '19 at 16:05
  • 1
    @buncis `.project` should not be in `.gitignore`. Regarding `.classpath` — if you use `m2eclipse` and your workspace is configured to update Maven projects on startup, then you _should_ be OK with adding `.classpath` to `.gitignore` but I haven't tested it myself. – Isaac Sep 20 '19 at 04:47
  • 2
    @buncis just correcting that last comment. Apparently, M2E does a very good job nowadays configuring projects. I recently worked on a codebase of approximately 150 Java projects of all types. I removed `.project` and `.classpath` from all of them and added to `.gitignore`. All works well and I don't need to endlessly update these files in Git too frequently. – Isaac May 13 '20 at 03:20
  • Will this create any problem if we push this .classpath file into the repo and if it is being pulled by other persons? – MrNolan Jul 16 '20 at 14:07
  • @MrNolan indeed, this is going to present a problem. However, if you use Maven, as well as the M2E plugin for Eclipse, you don't need to push `.classpath` to the repo. As a matter of fact, you shouldn't. – Isaac Jul 17 '20 at 17:03
12

Complete reference is not available for the mentioned files, as they are extensible by various plug-ins.

Basically, .project files store project-settings, such as builder and project nature settings, while .classpath files define the classpath to use during running. The classpath files contains src and target entries that correspond with folders in the project; the con entries are used to describe some kind of "virtual" entries, such as the JVM libs or in case of eclipse plug-ins dependencies (normal Java project dependencies are displayed differently, using a special src entry).

Zoltán Ujhelyi
  • 13,788
  • 2
  • 32
  • 37
5

This eclipse documentation has details on the markups in .project file: The project description file

It describes the .project file as:

When a project is created in the workspace, a project description file is automatically generated that describes the project. 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. This file is always called ".project"

senpai
  • 84
  • 1
  • 5