93

I'm running an open source java project that consists of multiple modules in a tree of dependencies. All those modules are subdirectories in a subversion repository. For newcomers to our project, it's a lot of work to set all that up manually in eclipse.

Not all our developers use eclipse. Nevertheless, we're considering to just check in the .classpath and .project files to help newcomers to get started. Is this a good idea? Or would that lead to constant conflicts in those files? Is there an alternative way to make the project easy to set up on eclipse?

amarillion
  • 24,487
  • 15
  • 68
  • 80
  • 1
    possible duplicate of [Shoul I keep my project files under version control?](http://stackoverflow.com/questions/116121/shoul-i-keep-my-project-files-under-version-control) – Steve Chambers Oct 09 '14 at 10:17
  • @SteveChambers Agreed, the other question was 2 years earlier. Strange that this question has been chosen not to be closed, but the older one. – questionto42 Jan 22 '23 at 20:29

7 Answers7

68

Definitively yes, as I said in "Do you keep your project files under version control?"

"Load it up, set it up, go."

But... this is actually true only for recent Eclipse3.5 settings, where build paths support relative paths:

Build path supports relative paths

And Eclipse3.6 would be better, as it supports relative paths for path variables in Linked Resources:

path variable with relative path
(since 3.6M5)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 2
    Wow, I didn't know they added this... Would have saved us some grief – Uri May 12 '10 at 14:20
  • It looks like the images associated with this answer are off-line. – vkraemer May 26 '11 at 03:37
  • 1
    @vkraemer: true. I have now restored those two pictures, the first one coming from http://archive.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/eclipse-news-part2.html and the second one from http://download.itemis.com/mirror/eclipse/R-3.6-201006080911./eclipse-news-part1.html. – VonC May 26 '11 at 04:03
18

Definitely no - it's generally terrible idea to distribute project files via subversion. Especially since someone might modify them in a some strange manner. A good page in the project's documentation is a much better idea. Our project also has many modules and a complex setup. We've set up a confluence page describing how to get started with the project on each populer IDE - IntelliJ, Eclipse, NetBeans. A README file in Subversion contains the same info.

Bozhidar Batsov
  • 55,802
  • 13
  • 100
  • 117
  • 34
    I can't agree. From my experience it is good to check theese files in to make the checkout as easy as possible. Someone might change them in some strange manner? Someone might change your code in some strange manner ... – Arne Deutsch May 12 '10 at 11:29
  • Arne, you should make that an answer, not a comment. – amarillion May 12 '10 at 11:51
  • 5
    The project files for any IDE are not actually part of any project - if you want to distribute them - go ahed - attach them to the article I mentioned. Generally everyone on a team can modify the files in the repo, but not everyone can attach new files to important documentation nodes, etc. It's very easy for someone to forget to ignore the classpath and project files and commit them when he shouldn't. Even if you keep them in subversion - you should certainly keep them somewhere on the side... – Bozhidar Batsov May 12 '10 at 13:01
  • 8
    -1, couldn't disagree more. Projects settings are a *crucial* part of the day-to-day work with a project. The disadvantages of accidentally checking in wrong settings are much smaller than the advantages of automatically keeping everyone up to date. After all, you can always easily go back to previous versions. – Michael Borgwardt May 12 '10 at 14:29
  • 7
    Everyone is entitled to an opinion. As a matter of fact I'd never create a project relying on Eclipse's(or any other IDE's) project system in the first place... Maven is the ultimate project comprehension tool and renders IDE specific setups obsolete. Btw the time to notice that something is wrong with the current settings and go back to previous revision is unlikely to differ from the time to adjust any new settings yourself. At least in my company everyone on the team gets notified via e-mail if some user intervention is required after bigger changes. – Bozhidar Batsov May 12 '10 at 14:59
  • Eclipse FAQ states, you should add them: https://wiki.eclipse.org/FAQ_How_do_I_set_up_a_Java_project_to_share_in_a_repository%3F – Stefan Apr 17 '20 at 05:22
11

I vote no, but that's because I would generally generate these files from maven

Goibniu
  • 2,212
  • 3
  • 34
  • 38
6

In my experience, excluding the limited cases where purely local settings are involved, everything should be in source control. The law of source control is that everything pushed in should be expected to work by those who pull out. Unfortunately, eclipse often causes things like this to be in .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

So on my Mac this works, and maybe someone on a Mac has the same JRE, but this will not work for anyone else.

Also, there's no easy way around this. Eclipse will always add that in. I WANT to have the .classpath file in there, because there are some 3rd party JARs in our lib folder where we care about versioning, so we leave them in there so new developers do not have to get them. We're moving to a managed system, but still have managed+unmanaged dependencies checked in. This means all the developers just have to ensure two directories are in their .classpaths. But it's better than having to fix your JRE every single time you pull and have a change in your .classpath every single time you commit.

Eclipse does some other nice things for you though. The .project file will usually be the same across instances, so include that. But the best thing about source control for eclipse is the Run Configurations settings. Under the "Common" tab in the Run Configurations dialog, save the configurations so they appear for your colleagues under the favorites lists for Debug and Run. For me, a bunch of .launch files go in the .settings directory, so we can all use them.

So I say: .settings directory goes into source control for launch configs (except *.prefs)

.classpath stays out

.project goes in.

Zak Patterson
  • 389
  • 5
  • 11
5

I would check theese files in to make the start for new users as easy as possible. At best the user should check out the project and should be able to run it without extra knowledge. For this files the rules are the same as for other files in the project: handle them with care. You should not place absolute pathes in the source code, neigther you should in the configuration files.

If the files are checked in in a way that the project runs from scratch there should not be much forces to change them.

Arne Deutsch
  • 14,629
  • 5
  • 53
  • 72
5

I would recommend that you check the files into subversion IF they do not contain absolute paths and other data which would tie them directly to a single developer's environment.

If the files do contain absolute paths and the like, a README would be a better choice.

vkraemer
  • 9,864
  • 2
  • 30
  • 44
3

Yes, definitely check them in, but make sure that you document any path dependencies and avoid absolute paths if possible.

If you don't check them in, then anyone checking the project out will need to recreate all of those settings, which is annoying and potentially error prone.

Some complex setups may be better handled by a script to generate these files, but usually it is better to just check them in.

Christopher Barber
  • 2,548
  • 1
  • 22
  • 23