What's Wrong with Build Systems in Java Today?
I think there's something fundamentally wrong with all build systems for Java that are available today.
The key point is not whether Ivy dependency management is better than Maven's. It's not whether Maven's plugins are good enough or not. And it's not that Maven's conventions can be mimicked by any other tool, even Ant.
The key points why build systems for Java are fundamentally broken are:
- They're not as efficient as they should be
- They're restrictive, especially for multi-project builds
Now I know that many people are happy with Ant. And I know many people are happy with Maven 2. And I'm happy for them. If you've found what you expect from a build system in Ant, Maven 2 or any other tool you should treasure it.
But there are many people who have not yet found what they need, especially people doing multi-project builds. For any serious software development effort the build system is a vital tool, a tool that can either restrict you or help you move ahead. Move ahead of your competitors for example.
If you're interested in build systems and multi-project builds then read this excellent post by Sherali Karimov on how Atlassian uses Maven 2. Although it's only the first post of four it gives you an idea of how important their build system and build configuration is to support their way of working. I'm sure it gives them an edge over their competitors. Or at least, if they would lose control over their build it would probably affect their progress, quality of their work, release management and with that their competitive advantage.
They're using Maven 2 and they seem to be doing okay. Yet we know from Don Brown's interview here on DZone - who also works for Atlassian - that they still lose time because of Maven 2.
The people at Atlassian have clearly made a dedicated commitment to get their build working the way they want it to. They're using Maven 2 but I'm sure that if they would have found a better tool they would be using that. In other words: they don't care which build tool they're using. They'll use the one that fits them best. It's today's reality that made them pick the tools that bothers them least.
How many people can you dedicate to set up your build tools according to your needs? I'm sure Atlassian would prefer to put these people on actual software development if a tool better than Maven 2 would require less effort. Every company or group of people serious about software development like Atlassian will indeed put in the effort it takes to get the build they need. It becomes wasteful if everybody serious about software development has to repeat these efforts.
What we need is a build tool that requires much less effort to configure it for anybody's needs. I know the limitations of Maven 2 and I know Atlassian would have a more flexible and easier to maintain build if they wouldn't be faced by those limitations. Yet they settle for what they have and I'm sure that after the time and efforts they've already invested they're happy with their build.
I'm also sure that if a new build tool would become available, say in the course of 2008, that has no limitations yet has similar or better conventions than Maven 2 they would certainly consider it. And if this new build tool would seamlessly integrate with their current Maven 2 build, maybe they would be even more eager to have a look. And if this new build tool would make their current Maven 2 build more powerful and versatile they may actually get excited.
What we need is a build system that marries Ant and Maven 2:
- A dependency programming framework inspired by Ant and Rake
- Maven 2's conventions by default, configurable if desired
- Domain models for the build domain that are lightweight, extensible and replaceable
- Re-use of Ant tasks where it makes sense
- Tasks that are at least as easy to develop as Ant tasks
- Plugins that are a magnitude easier to develop (and maintain) than Maven 2 plugins
- Better-than-Maven 2 JAR and project dependency management
- Integration of Ant, Maven 2, Gant, Buildr, Rake, Grails, ... projects in multi-project builds
- No XML
- Support for many dynamic languages + Java
Such a build system will become available in 2008 and this list is just a teaser. This build system will offer features most developers probably have never thought about.
2008 will be an interesting year for people interested in build systems. Check back to DZone to hear the news first.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)