Managing Jar Hell

When I moved from Netbeans to Eclipse, I couldn't understand why the Eclipse library support was so bad. By bad, I mean it doesn't support relative paths in its user libraries feature. You can see the bug report here. It was reported in July of 2004. Why is it that?

Well, it turns out, it's because the people at Eclipse know that you can handle this just fine now, probably not in 2004 though, using a dependency manager and it will do a much better job of it. Ultimately, the problem with the Netbeans approach, and to be fair, we'll see that Netbeans does support the alternatives suggested here, is that it requires you to check in library modules, the jar files, into source control or some kind of shared resources.

Enter Ivy... and moving on to Maven. Ultimately, these two systems work with Maven central do automatically grab all your jars for you. Not only, but they will also grab javadoc and source jars for you at the same time.

If you're struggling with this, give Ivy and Maven a look. I started using Ivy a little while ago and it worked like advertised but hit some limitations with the AppEngine SDK and native libraries (OpenGL and OpenCL bindings).

Ultimately, I moved our builds to Maven. Not only does Maven manage jar dependencies, including native libraries and big and complex SDKs like AppEngine and GWT, it also allows you to generate your IDE projects.

Having the maven project file be the authoritative source means we can generate projects for Eclipse or IntelliJ and Netbeans can read maven pom files directly. On many tasks, we can move away from Eclipse but still get access to all its plugins when we need it.

There are other up and coming systems like Buildr which uses Ruby instead of XML and Gradle that uses Groovy but for now, my build and dependencies are driven by Maven. Upgrading jars to never versions is changing one digit in an XML file. New team members just need to have a maven aware IDE and everything just starts. No setup time, no nothing.