How do you handle different Java IDEs and svn?

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. :).

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 (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).

I also like this answer, it is really good, too. Stackoverflow.com/questions/81567/… – Arvodan Sep 18 '08 at 5:46.

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.

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.

For the most part I'd agree with seldaek, but I'm also inclined to say that you should at least give a file that says what the dependencies are, what Java version to use to compile, etc, and anything extra that a NetBeans/Eclipse developer might need to compile in their IDE. We currently only use Eclipse and so we commit all the Eclipse . Classpath .

Project files to svn which I think is the better solution because then everyone is able too reproduce errors and what-not easily instead of faffing about with IDE specifics.

That's the same way we do it here up to now. If you lost all the information about dependencies and compilation, it is a huge mess for new developers to participate on the project. – Arvodan Sep 17 '08 at 10:07.

I'm of the philosophy that the build should be done with a "lowest common denominator" approach. What goes into source control is what is required to do the build. While I develop exclusively in with Eclipse, my build is with ant at the command line.

With respect to source control, I only check in files that are essential to the build from the command line. No Eclipse files. When I setup a new development machine (seems like twice a year), it takes a little effort to get Eclipse to import the project from an ant build file but nothing scary.(In theory, this should work the same for other IDEs, no?

Surly they must be able to import from ant? ) I've also documented how to setup a bare minimum build environment.

I use maven, and check in just the pom & source. After checking out a project, I run mvn eclipse:eclipse I tell svn to ignore the generated . Project, etc.

Here's what I do: Only maintain in source control your ant build script and associated classpath. Classpath could either be explicit in the ant script, a property file or managed by ivy. Write an ant target to generate the Eclipse .

Classpath file from the ant classpath Netbeans will use your build script and classpath, just configure it to do so through a free form project. This way you get IDE independent build scripts and happy developers :) There's a blog on netbeans site on how to do 3. But I can't find it right now.

I've put some notes on how to do the above on my site - link text (quick and ugly though, sorry) Note that if you're using Ivy (a good idea) and eclipse you might be tempted to use the eclipse ivy plugin. I've used it and found it to be horribly buggy and unreliable. Better to use 2.Above.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.