59

Should I check in my .project and .classpath files?

My friend told me that I should only check in .java files and the build.xml to guarantee portability. He said ".classpath will cause you much less portability on different environment. .project is entirely your local eclipse setting"

I agree with him, but partially.

-- Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)

-- Not checking in .classpath file seems OK to me (?) if my build.xml is written carefully.

Anyone wants to share their experience here?

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
sean
  • 817
  • 2
  • 9
  • 7
  • 6
    Note that if you use Maven and the m2eclipse plugin you will probably not need any of the settings from `.project` or `.classpath`. "import maven project" and "checkout maven project" will work fine with the `pom.xml` only. – Martin Aug 31 '10 at 18:56

10 Answers10

31

There is nothing wrong with checking in .project and .classpath. I would do so, if your build.xml isn't able to create both of the files for you. As you said, it's uncomfortable to miss these files when you try to create a new eclipse workspace.

Before you check in .classpath you should be sure that there is no absolute path in it. Convert it into a relative one with a text editor.

Edit: Or even better, use eclipse classpath variables in your otherwise absolute pathes, like @taylor-leese commented.

tangens
  • 39,095
  • 19
  • 120
  • 139
15

For my 2 cents, I would rate it as a bad practice. Projects should not be tied to an IDE, and especially should not be tied to a specific version of an IDE.

Checking in Eclipse config files might work well for simpler and short-term projects. For larger projects that are developed over several years this will generally cause more hassle, as IDE versions change, and project config files don't. Just imagine checking in a 2 year old branch with Eclipse 2.0 config files in Eclipse 4.3 with some customized libraries and m2e integration... No fun at all...

Nick G.
  • 557
  • 9
  • 18
11

One thing I would caution against with checking in .classpath file is make sure you don't reference files outside of your project. Eclipse stores the location of these files with a full filepath, and you would need to make sure other developers had those files in exactly the same place.

MikeTheReader
  • 4,200
  • 3
  • 24
  • 38
  • 3
    Agreed, but this can be avoided by using Eclipse classpath variables. This way the .classpath file can stay the same for each developer and they can just modify the classpath variable for their specific machine. – Taylor Leese Aug 31 '10 at 18:10
9

The key question with all such files is "Can they be reproduced automatically?" If not, check them into source control.

In this case, I'd say "yes," unless you're using maven, which has m2eclipse and the eclipse plugin to generate them for you.

Dominic Mitchell
  • 11,861
  • 4
  • 29
  • 30
  • i think you meant "In this case, I'd say 'no, they can't be reproduced automatically,'" – Lance Kind Dec 19 '19 at 16:29
  • I agree with your meaning. As written you've got two questions. The implied question: "shall I check them in?" And the explicit question: "can they be reproduced automatically?" And so when you said "yes" you meant the implied question. – Lance Kind Dec 19 '19 at 16:30
  • So to clarify : if you're using maven, then you DON'T need to commit these files (.project, .classpath) ? – GeneC Mar 23 '20 at 15:09
3

I don't really know eclipse preferences files, but with IntelliJ, those files are OS agnostics, which means that it won't ruin your portability. Unless you define libraries with a full path to your system (That would be pretty dangerous/stupid).

When you share preferences, you're sure that everyone will work with the same conditions on the project (plugins configuration, encoding, profiles [for intelliJ]) which can really be a good thing.

It doesn't bother me when some Eclipse files are here, and I think it shouldn't/doesn't really bother other developers when some hidden files just lay there.

Colin Hebert
  • 91,525
  • 15
  • 160
  • 151
3

We check in .project and .classpath. With ProjectSet's this allows us to check out complex workspaces with a single "Import Team ProjectSet"

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
2

Not checking in .project file will make my development less efficient (I can't simply "import" a project code from a directory)

for this issue, you can choose to create new project and import existing source.

one issue with IDE specific files like .project is that other Developers may want to use another IDE do develop the project, so they may add another type of project files. this will make your repo messy.

mhshams
  • 16,384
  • 17
  • 55
  • 65
  • ... and this would also include the right jars into the classpath, set the project's compiler compliance level, and load the formatter and compiler warnings configuration? – meriton Aug 31 '10 at 17:57
  • Or you have an agreement on which IDE to use and everyone gets the productivity improvement. – Samuel Åslund Aug 08 '14 at 08:10
1

I would prefer to checkin .project and .classpath.

This would be helpful when this project is being shared by multiple developers. It becomes easy and faster to setup development env. by simply importing this as existing project on any system using eclipse.

Only caution needs to be taken here is classpath's are relative to project.

YoK
  • 14,329
  • 4
  • 49
  • 67
1

I often have a similar, more general questionning. The problem essentially is :

  • which files am I commiting for me?
  • which files am I commiting for others?
  • → How do I combine both objectives of "versionning"?

I offered discussing this there, so you may find more details about the problem, along with interesting solutions :)

The one I like best is the use of git submodule: keep your .project files etc. in a private commit repo. And make your final, pure, essential src production into a neat submodule nugget: a public repo.

project/ # root module
|   .git # private repo
|   .project
|   .classpath
|   momsNumber.txt
+---src/     # submodule
|   |   .git # public repo
|   |   main.java
|   +---package/
|   |   |    Etc.java

See there anyway.

Community
  • 1
  • 1
iago-lito
  • 3,098
  • 3
  • 29
  • 54
0

There is not problem of checking in .classpath and .project files into repository. It will help developers which use Eclipse to get going faster.

Warning: Make sure your .classpath file is referencing only artifacts which either checked into the repository with the project or can be obtained automatically (such as maven artifacts).

Eugene Ryzhikov
  • 17,131
  • 3
  • 38
  • 60