Main / Personal projects / Ant and Eclipse

Ant is a well known cross platform build tool. Eclipse is a pluggable Java IDE. Eclipse has many built in refactorings that save a ton of time. (rename package, rename method, move class, change method signatures, etc) However many of its cool features require compiling and running Java code within Eclipse, so it needs to know the project classpath. It stores that classpath in a “.classpath” file in the project directory, but as far as I know, it does not have good hooks to read the classpath from something like a Makefile or an ant build.xml. Therefore I wrote an ant target that knows how to write an eclipse .classpath file, so you can store the classpath in the build.xml and read it from Eclipse.

This build file contains a target that generates the .classpath file based on the ant classpath. If you use this target, you will no longer be able to modify the .classpath file from within Eclipse; you’ll have to maintain it by hand in the build.xml. You can use Eclipse to make changes to the .classpath file but you have to manually copy them to the build.xml to persist them. Since the whole point of this hack is to maintain the classpath in ant instead of Eclipse, this isn’t such a bad thing. The problem is that the Eclipse classpath file contains metadata about classpath entries, such as the location of the source code for a jar.

This ant target works in the opposite direction, putting the Eclipse .classpath file into an ant path. I think this is evil in principle because the IDE should conform to the build tool rather than vice versa. Otherwise, you can’t support multiple IDEs. However, it has its points since the Eclipse .classpath file is more expressive than ant.