Most people eventually get it that building release artifacts using their IDEs is not the way to nirvana. Builds have to stay stable and reproducible between IDE revisions, and being able to execute them in a command line environment or especially continuous integration servers is key to agile development.
Fortunately, there are open source build tools for Java. Less fortunately, they're not quite perfect. Let's see what we've got.
The Sorry State of Affairs
There's Ant, the undying classic, but pretty much in maintenance mode, I understand. Ant-based build systems usually start small and innocent but quickly turn into a tangled mess. Every Ant script is a unique piece of modern art that has to be deciphered on its own. They are the cockroaches of Java development, and I guess we'll have to deal with them again in 30 years when we'll be porting ancient Java applications to the next big platform.
Maven 2 promises relief and introduces convention over configuration, dependency management, lifecycle support and a few other things that aren't strictly relevant for a build system. Great concepts, but the actual implementation makes you want to cry. The state of documentation is poor, the XML syntax is unnecessarily bulky, and trivial one-off tasks aren't possible without a proper plugin (go and write one if you're feeling brave). Not to mention that stunts like multi-module projects are necessary to build a simple EAR file. And no, Eclipse doesn't like them either.
Despite all its shortcomings, a lot of people including me tried hard to love Maven, but it's not easy.
The Winds of Change
Where does that leave us?
I don't have much hope for Ant. It is what it is and lacks too many things a build system needs, most importantly built-in conventions and higher level abstractions. Granted, there's Ivy, a pretty nice dependency manager that adds a couple of interesting features, but that's about it (Ivy looks heavily inspired by Maven, but it's funny how they changed all the terminology).
Maven 2's future looks a little bit brighter since it seems the project is opening up to common sense, which maybe be a direct effect of recent discussions and probably Don Brown's patches. For example, the XML syntax in 2.1.0 will be much more concise and there are fixed default plugin versions in 2.0.9 so that it's easier to have reproducible builds. Unfortunately, the public repository is a swamp of misplaced software and crappy metadata, so there may be no alternative to setting up a local repository.
At the moment, I'm taking a closer look at Buildr, a ruby-based build system for Java that's currently under incubation at the ASF. Apparently they're creating a better Maven, taking the proven concepts but none of its implementation. The jury's still out on whether the average coder will be able to create effective, maintainable build scripts, but we'll see. Having to learn Ruby may be a problem to some and an incentive to others.
So?
Poor build systems and development environments in general are a barrier for new project members and a frequent cause for frustration. I've worked on projects where all you had to do was to check something out from Subversion, type "mvn package" and you were ready to go. For other projects (both commercial and open source!) you needed a specialist's support, a couple of days time and a lot of hand-holding to actually build the product and run it locally.
Unfortunately, only few development shops realize that a decent development environment is an asset and invest in their build infrastructure. A good project setup takes time, and if there's no time or budget available, your build tool of choice won't do any wonders on its own.