Multi IDE version controlled Java project - Is it possible to do it seamlessly?

Question

I have a Java project where:

Multiple people will work on it with version control (git in particular)
People want to use different IDE's to work (Netbeans and Eclipse are the main contenders)

The problem is in maintaining project files which are independent of the IDEs, but at the same time can be easily imported into both IDEs.

I have considered the following possibilities, but wasn't happy with them:

Maven project - This seems to be the most seamless, but for multiple reasons we have opted out of using Maven
Have a Netbeans project with gitignores and do a Ant project in Eclipse - Not sure about the build.xml format conflicts. Plus it's not so seamless for eclipse.
Have only the organised sources with a manually managed build.xml - Manual Ant is a hassle. And importing these isn't that seamless.

Personally I'm leaning towards the third solution as it seems more generic (despite the hassle). Any suggestions are welcome.

Mark O&#39;Connor · Accepted Answer

Recommended approach

The choice of source code editing environment can be highly contentious, in a software development project.

Rather than take sides, I have always mandated the following simple rules:

Builds must be performed without dependencies on an IDE or IDE plugin
IDE configuration files must not be checked into version control

Why?

The first rule is common sense, it's the latter rule that generates controversy. Each IDE has its own settings format, additionally these files tend to be very specific to the developers machine. It's simply not practical to track collective changes to these files.

Instead, I encourage encourage developers use build tool plugins, for their chosen IDE. This is really the reason behind the popularity of Maven, the "pom.xml" file has become a common standard for determining a project's build classpath (cross IDE support).

What if Maven is not an option?

Gradle

A very fine build tool that appears to have adopted some of the modern approaches of Maven, but preserves the control of ANT. It's build files may appear alien at first (no XML), but tend to be shorter and simpler to understand

http://www.gradle.org/

ANT + ivy

ANT pre-dates Maven so has no standard way to track it's classpath. It's left up to the "build.xml" author.

The best solution is to integrate the apache ivy plugin. It also has plugins for both Eclipse and Netbeans

ANT

If you'd prefer the traditional "do-it-myself" ANT approach, then you can create additional targets in your build file, generating the configuration files required by your supported IDEs.

For example, the answers to the following question give two approaches for generating Eclipse's ".project" file:

Using Ant's classpath in Eclipse