How do you handle different Java IDEs and svn?

Question

How do you ensure, that you can checkout the code into Eclipse or NetBeans and work there with it?

Edit: If you not checking in ide-related files, you have to reconfigure buildpath, includes and all this stuff, each time you checkout the project. I don't know, if ant (especially an ant buildfile which is created/exported from eclipse) will work with an other ide seamlessly.

Answer 1

We actually maintain a Netbeans and an Eclipse project for our code in SVN right now with no troubles at all. The Netbeans files don't step on the Eclipse files. We have our projects structured like this:

sample-project   
+ bin
+ launches  
+ lib  
+ logs
+ nbproject  
+ src  
  + java
.classpath
.project
build.xml

The biggest points seem to be:

• Prohibit any absolute paths in the project files for either IDE.
• Set the project files to output the class files to the same directory.
• svn:ignore the private directory in the .nbproject directory.
• svn:ignore the directory used for class file output from the IDEs and any other runtime generated directories like the logs directory above.
• Have people using both consistently so that differences get resolved quickly.
• Also maintain a build system independent of the IDEs such as cruisecontrol.
• Use UTF-8 and correct any encoding issues immediately.

We are developing on Fedora 9 32-bit and 64-bit, Vista, and WindowsXP and about half of the developers use one IDE or the other. A few use both and switch back and forth regularly.

Answer 2

The smart ass answer is "by doing so" - unless you aren't working with multiple IDEs you don't know if you are really prepared for working with multiple IDEs. Honest. :)

I always have seen multiple platforms as more cumbersome, as they may use different encoding standards (e.g. Windows may default to ISO-8859-1, Linux to UTF-8) - for me encoding has caused way more issues than IDEs.

Some more pointers:

• You might want to go with Maven (http://maven.apache.org), let it generate IDE specific files and never commit them to source control.
• In order to be sure that you are generating the correct artefacts, you should have a dedicated server build your deliverables (e.g. cruisecontrol), either with the help of ant, maven or any other tool. These deliverables are the ones that are tested outside of development machines. Great way to make people aware that there is another world outside their own machine.
• Prohibit any machine specific path to be contained in any IDE specific file found in source control. Always reference external libraries by logical path names, preferable containing their version (if you don't use maven)

Answer 3

The best thing is probably to not commit any IDE related file (such as Eclipse's .project), that way everyone can checkout the project and do his thing as he wants.

That being said, I guess most IDEs have their own config file scheme, so maybe you can commit it all without having any conflict, but it feels messy imo.