8

I inherited a Java project in the form of an Eclipse project. After changing the Tomcat configuration (from v6 to v7), Subclipse prompted me to commit the following files:

  • .classpath
  • org.eclipse.core.prefs
  • org.eclipse.common.project.facet.core.refs
  • org.eclipse.common.project.facet.core.xml

Will commiting them help my team members or will it mess with their workspace?

What is the best practice approach to this?

Lii
  • 11,553
  • 8
  • 64
  • 88
Dimitrios Mistriotis
  • 2,626
  • 3
  • 28
  • 45
  • 3
    See http://stackoverflow.com/questions/116121/do-you-keep-your-project-files-under-version-control/119377#119377, or http://stackoverflow.com/questions/2024307/what-should-be-committed-to-the-repository-in-the-eclipse-workspace , or (more generic) http://stackoverflow.com/questions/1880817/what-to-put-under-version-control – VonC Jan 27 '11 at 11:11
  • 1
    Wow. I tried to look around a bit. I think that my question can "break" into two or three and get for each one of them proper responses. I believe the best answer would be your comment :-) – Dimitrios Mistriotis Jan 27 '11 at 13:36

8 Answers8

11

Generally speaking, you should check-in (and commit after changes) everything that does contribute to the build AND is not re-generateable by re-building completely AND is workstation-specific. (The implications of this statement depend on your build process/procedure, which is intended.)

This implies you should exclude everything that is re-generated upon full build etc. so it is not checked in (and not offered for check-in).

TheBlastOne
  • 4,291
  • 3
  • 38
  • 72
  • 3
    This also implies that all the files in the question should be examined for workstation-dependent things like file paths and user preferences. And if there is nothing workstation or user dependent in some of them, then there is nothing wrong with committing that particular files. For example, .classpath may contain file system paths, but maybe it just contains workstation-independent library names and paths for them are defined elsewhere. – Sergei Tachenov Jan 27 '11 at 10:25
  • @Sergey Tachenov: Yes, and that's what I meant with "The implications of this statement depend on your build process/procedure, which is intended." – TheBlastOne Jan 27 '11 at 10:34
  • 1
    I checked everything and saw that the files were all path independent. I thought that in the Eclipse everything would be either path independent or dependent, but not both... – Dimitrios Mistriotis Jan 27 '11 at 13:33
5

As a general rule, you should avoid committing files that contain user preferences, and project details that that Eclipse and/or your plugins can regenerate.

But in some cases things are a bit murky. For instance, the .classpath file can be the primary source of the Eclipse build path; e.g. if you have JAR files in your project tree rather than using Maven. (With Maven, the m2eclipse plugin generates the .classpath file from the dependency information in the POM file, and hence the file should not be checked in.)

Also, some of the facet stuff is borderline. For instance, in projects with JSPs and Javascripts, I have found it essential to change the facet properties to disable broken validators. And there's a good case for treating those changes as part of the project rather than as personal preferences.

Separation of group / project preferences from personal preferences is one area where (IMO) Eclipse is seriously deficient.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Are other IDEs better, and if so, how? I think eclipse is so-so: it's great to have the essential project configurations as text files within the project directory. It's not so great to have them distributed over various files in various formats. – Michael Borgwardt Jan 27 '11 at 10:40
  • @Michael - *"Are other IDEs better"* - seriously, I don't know. And its probably one of those things that is too hard / too late to fix. – Stephen C Jan 27 '11 at 14:23
4

It is better not to commit those files as paths/settings may differ on different workstations.

You may wanna use some build tool to overcome this. (eg. Maven)

As if any of the team members are not using eclipse (using some other ide) , those files have no meaning for them.

If everyone commits different IDE settings, imagine what kind of mess it can cause.

EDIT:

More explanation;

I have worked in teams that people used NetBeans, Eclipse, IDEA...for a really long time and it is not really an option for them to change the IDE. It will only affect the productivity of that person.

When people get used to their IDEs they learn shorcuts, they know where to look for some functions (refactor/generate getter setter/implement override required methods....) so if you force them to use some other IDE it will just make things harder for them and slower for the overall process. IMHO and from my experience having a flexible codebase is always good. I am an eclipse guy and probably would not want to work with any other IDE as I know lots of shorcuts which makes thing real quicker/easier for me and those shorcuts are different on different IDEs.

All IDE files can be regenerated automatical by the IDE itself probably in just a couple of clicks.

And my current project has 3 developers, each using different IDEs eclipse(me), NetBeans, IDEA without any problems. I dont want to see IDEA or NetBeans config files which makes no sense for eclipse when I check out the source from repo. Likewise for them as well.

fmucar
  • 14,361
  • 2
  • 45
  • 50
  • +1 for the workstation-specific aspect. In return, I allowed myself to add this aspect to my own answer. – TheBlastOne Jan 27 '11 at 10:15
  • "by whom? Why?" :) complete question sentence will make me understand what the question is? – fmucar Jan 27 '11 at 10:30
  • @fatih: OK. "This was downvoted by one -- by whom? And why?" Better? – TheBlastOne Jan 27 '11 at 10:36
  • 1
    downvote was from me, because none of these (except for the reference to Maven) are good arguments for avoiding the substantial benefits of checking in these files. – Michael Borgwardt Jan 27 '11 at 10:45
  • Standardizing on an IDE or letting everyone use what they know best is a tradeoff with advantages and disadvantages on both sides. But "not wanting to see" config files from other IDEs is still a very poor reason for not having them in source control. They help the people with that IDE and are at worst a minor annoyance for everyone else. – Michael Borgwardt Jan 27 '11 at 14:09
  • Pls name a couple of advantages for forcing people use some specific IDE. As mentioned before, all IDE specific files are auto-generated and can be regenerated by IDE again easily, however it may make life easier for some who do not know how to do that in the IDE they are using but i still don't see this as a good reason to commit generated files – fmucar Jan 27 '11 at 14:27
  • @fatih, if the advantages are not clear by now I dunno what to say. I'll try: Using a team-widely standardized IDE allows you to agree upon the config details we just discussed. If everybody uses what he/she wants, you can prepare for repeated phases of chaos where someone (the build manager?) has to debug where what came from, and why, and what symptoms are the culprits. Of course, it might have an individual productivity advantage if one can use what one knows best. Being a fan of standardized team behavior, I'd vote for the common IDE idea. – TheBlastOne Jan 31 '11 at 10:30
  • fatih, I'd add: If you standardize the IDE aspects, you can build up one "expert group" which creates the IDE config, and deploys them by checking it in. So not everybody has to find solutions to questions that we just answered. I love that. – TheBlastOne Jan 31 '11 at 10:33
4

Yes, though do make sure that paths are relative in the workspace rather than absolute paths. Having these files in the workspace allows members of your team to work in the same environment as you are. It also makes setting up a new development environment much easier: you just check it out of source control and in Eclipse use 'Import... > Existing Projects into Workspace'

As @adamdunne mentioned, these files can contain environment specific paths. However it if you are careful to make sure paths are relative within your workspace, by using variables and by not importing external jars, i.e., by only including jars from projects in the workspace, then you should be okay. In my workspace we check in those files and have had a lot less issues setting up dev. environments since.

corriganjc
  • 660
  • 7
  • 21
  • +1 for indicating how to get rid of workstation-specific config details. – TheBlastOne Jan 27 '11 at 10:26
  • We did that ( 'Import... > Existing Projects into Workspace') and this is the reason I asked the question in the first place. Currently my team is in training mode and I want to adopt as many best practices as I can for the project's life cycle. – Dimitrios Mistriotis Jan 27 '11 at 13:31
1

I work in a project where we commit the .classpath file since it is very useful that all developers use the same :) If you only use dependencies inside your workspace, this file uses relative paths and thus should be same on all machines. Even if this file might not be necessary to build (with ant e.g.) it´s very convenient to synchronize it.

In contrast the org.eclipse.core.prefs stores (afaik) project-specific, but personal preferences of developers which I would not check in.

With the facets I didn´t work yet in a real project, so I can´t tell. But in general, I think it depends on the information in the file and on the way you work.

If you are unsure, just try it. If you get conflicts in these files all day this is a hint you may not be on the perfect way.

mkraemerx
  • 1,713
  • 2
  • 17
  • 21
  • 1
    >>If you are unsure, just try it. << And let the rest of the team enjoy that experience immediately, as well, hehehe. If you get conflicts in these files all day, it is a hint that the rest of the team gets them, too, and you successfully bombed the build :) – TheBlastOne Jan 27 '11 at 10:29
  • >> If you get conflicts in these files all day this is a hint you may not be on the perfect way.<< Duke Nukem would say: "Hehehehehe, what a mess." :) – TheBlastOne Jan 27 '11 at 10:30
  • org.eclipse.core.prefs stores things like the Java compiler source and target versions and warning/error settings, which I would actually consider quite useful NOT to have every developer decide for themselves. – Michael Borgwardt Jan 27 '11 at 10:35
  • The comment from @Michael... Where can I find out where Eclipse stores what? – Dimitrios Mistriotis Jan 27 '11 at 13:38
  • @dimitris: that's the problem... I don't think it's officially documented anywhere. But the config files are generally quite readable. – Michael Borgwardt Jan 27 '11 at 14:04
1

These files can be very useful to share configurations between developers. The alternative is to either use Maven (which is a huge task for an established project) or to have constantly-outdated step-by-step instructions and new developers taking half a day until they can even build the project.

However, you should take care to ensure that these configurations are portable, i.e. contain no local paths. This can be done via the use of relative paths within the workspace, eclipse path variables and user libraries.

Michael Borgwardt
  • 342,105
  • 78
  • 482
  • 720
  • I also wrote it in a different comment, I believed that eclipse had all paths relative or absolute but not both. This is the main reason I posted this question. Based on this and similar advices I started reviewing every file and saw what was going on in each one of them. Thanks a lot. – Dimitrios Mistriotis Jan 27 '11 at 13:58
  • @dimitris: It's definitely possible to have both. For example, when adding a JAR to the project's build path (which results in an entry in the .classpath file), you have the options "Add JARs", which lets you choose a file from within the workspace and generates a relative path, and "Add External JARs", which lets you choose any file and generates an absolute path. – Michael Borgwardt Jan 27 '11 at 14:13
0

What we've done is ignore these files, as they may mess up the workspace of others on the project.

Ignoring them also makes your project cleaner, which I always like.

Chris
  • 51
  • 4
  • I did not do that downvote, however I guess the downvoter considered "cleaner" too vague, as might be the case for "mess up the workspace". The typical so newbee situation: You try, and get bumped away. Keep going, @cgratgny, learn from it, and your point balance will explode sooner or later. Just don't get frustrated by this initial learning curve, it can be considered normal. – TheBlastOne Jan 27 '11 at 18:48
  • Thanks for the comment, @TheBlastOne. I know I was trying.. just not so eloquent as others in the solutions they provide. – Chris Jan 30 '11 at 20:15
0

These files can contain environment specific paths so I would suggest not checking them in. On my current project we use ant scripts to create the project and do the initial checkout of all our code.

adamdunne
  • 113
  • 1
  • 2
  • 7