Home/ Questions/Q 112251
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T02:30:55+00:00

I’m soon going to check in the very first commit of a new Java

  • 0

I’m soon going to check in the very first commit of a new Java project. I work with Eclipse Ganymede and a bunch of plug ins are making things a little bit easier.

Previously I’ve been part of projects where the entire Eclipse project was checked in. It’s quite convenient to get the project settings after a check out. However this approach still was not problem free:

  • I strongly suspect that some Eclipse configuration files would change without user interaction (from when I used Eclipse Europa), making them appear as changed (as they were changed, but not interactively) when it’s time to do a commit.
  • There are settings unique to each development machine as well as settings global for all developers on a project. Keeping these apart was hard.
  • Sometime if the Eclipse version was different from others Eclipse would get angry and mess up the project configuration. Another case is that it change the format so it gets updated, and if commited messes up the configuration for others.

For this specific project I have another reason not to commit the project files:

  • There might be developers who prefer NetBeans which will join the project later. However they won’t join within the coming months.

How do you organize this? What do you check into versioning control and what do you keep outside? What do you consider best practice in this kind of situation?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. At a minimum you should be check-in the .project and .classpath files. If anybody on your team is hard-coding an external JAR location in the .classpath you should put them up against the wall and shoot them. I use Maven to manage my dependencies but if you are not using maven you should create user libraries for your external JARs with with a consistent naming convention.

    After that you need to consider things on a plug-in by plug-in basis. For example I work with Spring so I always check-in the .springBeans and likewise for CheckStyle I always check-in the .checkstyle project.

    It gets a bit trickier when it comes to the configuration in the .settings folder but I generally check-in the following if I change the default settings for my project and want them shared with the rest of the team:

    • .settings/org.eclipse.jdt.ui.prefs – it contains the settings for the import ordering
    • .settings/org.eclipse.jdt.core.prefs – it contains the settings for the compiler version

    In general I haven’t noticed Ganymede modifying files without me modifying the project preferences.

    • 0