3

My team handles several Java projects using Eclipse, and shares the code using a code repository.

When a developer adds, removes or updates a jar file, the build is broken for everybody else, until they update their build path in Eclipse. This process involves cumbersome email synchronization.

For several reasons, we have decided not to commit the .classpath file to the repo. Instead, we came up with the following idea: Each project will have a committed file, say jars.list, which contains a list of jar files (and patterns). A script will convert this file into a local .classpath for eclipse. Whenever a developer changes its jars, it is his or her responsibility to change jars.list and commit it.

Is this a reasonable solution? Are there any existing solutions for this problem?

Adam Matan
  • 128,757
  • 147
  • 397
  • 562
  • Checking .classpath and .project into source control is the intended approach - they're designed to do that. Why are you not doing that? – E-Riz Apr 24 '12 at 21:33
  • I'm afraid that there will be many conflicts due to personal configurations. – Adam Matan Apr 25 '12 at 07:38
  • That doesn't make any sense. The `.classpath` file is intended to be shared; you can keep it free from absolute paths through a variety of techniques, such as storing JARs in the project, having a separate "Libs" project, using Classpath Variables, etc. The bottom line is that chcking in `.classpath` is the intended way to do what you're trying to do with some elaborate, manual process. – E-Riz Apr 25 '12 at 14:35
  • @E-Riz Thanks. a. Do you know where can I find reference to the fact that `.classpath` is inteneded to be shared? b. Could you please post it as an answer? I would like to accept\upvote if it's the solution I pick. – Adam Matan Apr 26 '12 at 18:48
  • 2
    I don't agree with E-Riz, commit IDE auto-generated files into version control is not a good practice, you can never guarantee that all developers within a team use exactly same development environment (same OS, same IDE, same JDK, or even same project folder path). if the number of jar files become tremendous, consider using Ant (with Ivy) or Maven manage jar dependencies, as an ultimate solution. – yorkw Apr 30 '12 at 02:23

2 Answers2

4

Eclipse .project and .classpath files are intended/designed to be checked into a version control repository (cvs, svn, git, etc). See this page in the Eclipse wiki.

There are various ways to keep the .classpath file "clean" (ie, free from absolute paths), which I mentioned in the Comments section above.

E-Riz
  • 31,431
  • 9
  • 97
  • 134
  • Looks like the right approach. The only problem is the JRE, which are manifested in the `.classpath` but are machine-specific: http://stackoverflow.com/questions/10371512/eclipse-classpath-in-svn-jre-collision – Adam Matan Apr 29 '12 at 10:46
  • As one of the answers to that question points out, using an Execution Environment is the right way to specify the Java version that you want. Machine-specific JRE specifications are an historical remnant and really should be removed from the configuration options, IMO. Execution Environments are an abstraction above the physical JRE location that keeps your .classpath "clean" and portable. – E-Riz Apr 29 '12 at 22:04
2

The build is broken because the absolute path to the JAR is different in each developer machine? If so, you could add a user variable to avoid the issue, this way each developer only have to configure one variable (like LIB_DIR):

<classpathentry kind="var" path="LIB_DIR/path/to/file.jar"/>

There are other solutions. You could configure some user libraries in eclipse to group your JARs, and then export a .userlibraries file which could be shared in your repo. This way, there would be no absolute paths in .classpath, but they would be present in your .userlibraries.

You could also use some tool like Maven to manage dependencies on your project.

Anyway, I think you could share .classpath without problems...

André
  • 12,497
  • 6
  • 42
  • 44