Comments on: Comparing Build Systems http://www.symphonious.net/2010/01/11/comparing-build-systems/ Living in a state of accord. Tue, 07 Feb 2012 01:07:58 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: James Lorenzenhttp://www.symphonious.net/2010/01/11/comparing-build-systems/comment-page-1/#comment-174700 James Lorenzen Sat, 27 Mar 2010 02:30:36 +0000 http://www.symphonious.net/?p=1274#comment-174700 In my 10+ year java career, I've gone from simple .bat scripts, to ant, to maven 1, and now maven 2. IMHO, each was an improvement on it's predecessor. I still keep up with the latest java build tools. Really like your "real-world" comparison and not just some Hello World example. If you liked ant a lot and gradle, you might really enjoy gant (http://gant.codehaus.org/). I believe it is what grails uses. Instead of Ant XML it's groovy. I think it also suffers from groovy startup times, but I use it for small scripts in maven using the gmaven plugin. It's also nice that you can use ant/gant in maven using the antrun plugin. In my 10+ year java career, I’ve gone from simple .bat scripts, to ant, to maven 1, and now maven 2. IMHO, each was an improvement on it’s predecessor. I still keep up with the latest java build tools. Really like your “real-world” comparison and not just some Hello World example. If you liked ant a lot and gradle, you might really enjoy gant (http://gant.codehaus.org/). I believe it is what grails uses. Instead of Ant XML it’s groovy. I think it also suffers from groovy startup times, but I use it for small scripts in maven using the gmaven plugin. It’s also nice that you can use ant/gant in maven using the antrun plugin.

]]> By: SJGhttp://www.symphonious.net/2010/01/11/comparing-build-systems/comment-page-1/#comment-174653 SJG Mon, 01 Mar 2010 20:47:23 +0000 http://www.symphonious.net/?p=1274#comment-174653 An interesting alternative to Buildr, if you don't want the maven-style dep. management: http://www.engineyard.com/blog/2010/rake-and-ant-together-a-pick-it-n-stick-it-approach/ (of course, you can still call out to Ant and use Ivy!) What makes this interesting is for shops that do multi-language work, such as Java and .NET. You can use Rake for both (single learning curve), and just plug in the needed pieces for language specific needs (ie., calling ANT tasks for java-specifics, or calling MSBuild via Albacore for .NET specifics). An interesting alternative to Buildr, if you don’t want the maven-style dep. management: http://www.engineyard.com/blog/2010/rake-and-ant-together-a-pick-it-n-stick-it-approach/ (of course, you can still call out to Ant and use Ivy!)

What makes this interesting is for shops that do multi-language work, such as Java and .NET. You can use Rake for both (single learning curve), and just plug in the needed pieces for language specific needs (ie., calling ANT tasks for java-specifics, or calling MSBuild via Albacore for .NET specifics).

]]> By: Maurice Naftalinhttp://www.symphonious.net/2010/01/11/comparing-build-systems/comment-page-1/#comment-174500 Maurice Naftalin Tue, 12 Jan 2010 10:13:16 +0000 http://www.symphonious.net/?p=1274#comment-174500 Thanks for this post. Your explanation of how to approach Maven is the best I've ever seen. It should be required reading for every potential Maven adopter. If that happened, 95% would go elsewhere while the remaining 5% would have a good chance of success. That would be a big improvement on the present situation! Thanks for this post. Your explanation of how to approach Maven is the best I’ve ever seen. It should be required reading for every potential Maven adopter. If that happened, 95% would go elsewhere while the remaining 5% would have a good chance of success. That would be a big improvement on the present situation!

]]> By: Adrian Suttonhttp://www.symphonious.net/2010/01/11/comparing-build-systems/comment-page-1/#comment-174498 Adrian Sutton Tue, 12 Jan 2010 06:51:27 +0000 http://www.symphonious.net/?p=1274#comment-174498 Hi Hans, Thanks for the extra info - Gradle is clearly going to keep improving over time and really does show a lot of promise. The improvements in startup time will definitely be very useful - slow start up really does cause big problems when you're doing things like tweaking JavaScript or JSPs because you want to rerun the quick copy task to redeploy regularly but a slow start up makes it take too long. It's obviously important to make the overall build fast as well for things like continuous integration and when you need to do a full build, so it's great to hear you have some big improvements coming there too. I'll definitely keep my eye on Gradle going forward. Hi Hans,
Thanks for the extra info – Gradle is clearly going to keep improving over time and really does show a lot of promise. The improvements in startup time will definitely be very useful – slow start up really does cause big problems when you’re doing things like tweaking JavaScript or JSPs because you want to rerun the quick copy task to redeploy regularly but a slow start up makes it take too long.

It’s obviously important to make the overall build fast as well for things like continuous integration and when you need to do a full build, so it’s great to hear you have some big improvements coming there too. I’ll definitely keep my eye on Gradle going forward.

]]> By: Hans Dockterhttp://www.symphonious.net/2010/01/11/comparing-build-systems/comment-page-1/#comment-174497 Hans Dockter Tue, 12 Jan 2010 06:41:31 +0000 http://www.symphonious.net/?p=1274#comment-174497 Hi Adrian, Thanks for this interesting comparison. We have made the 'current project' behavior in Gradle more intuitive in 0.9. Talking about build times. One important factor of our start up time is the Groovy startup time. The Groovy team is working on improving that. Groovy 1.7.1 will already start up faster. There is more to come for Groovy 1.8. But after all the relevant build time is the average build time. With the very smart incremental build feature already in Gradle trunk and which will be part of 0.9, Gradle is for many complex builds the fastest build system around. Gradle 0.9 will be released in the next weeks. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz Hi Adrian,

Thanks for this interesting comparison.

We have made the ‘current project’ behavior in Gradle more intuitive in 0.9. Talking about build times. One important factor of our start up time is the Groovy startup time. The Groovy team is working on improving that. Groovy 1.7.1 will already start up faster. There is more to come for Groovy 1.8. But after all the relevant build time is the average build time. With the very smart incremental build feature already in Gradle trunk and which will be part of 0.9, Gradle is for many complex builds the fastest build system around.

Gradle 0.9 will be released in the next weeks.

- Hans

–
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. – Gradle Training, Support, Consulting
http://www.gradle.biz

]]> By: Odihttp://www.symphonious.net/2010/01/11/comparing-build-systems/comment-page-1/#comment-174494 Odi Mon, 11 Jan 2010 17:55:26 +0000 http://www.symphonious.net/?p=1274#comment-174494 I have always hated this Maven pest. It's a pain to get it to do what you want. And every time you open a project that you haven't built for 6 months Maven will find a new reason why it won't build, be it just because your Maven version is now deprecated. With Ant you get the job done in 10% of the time. And it doesn't take your entire dev team to read a Maven book. Even Ant has it's drawbacks: programming in XML is the first, and programming in a declarative language (no loops, variables, real if/elses) is the second. For me Maven is out of question, and what remains is a decision between bash script and Ant. At the end of the day, all we want is to fire up the compiler and junit, archive and move some files around and perform some trivial edits in text files. If that task takes a monster like Maven, something is dead wrong. I have always hated this Maven pest. It’s a pain to get it to do what you want. And every time you open a project that you haven’t built for 6 months Maven will find a new reason why it won’t build, be it just because your Maven version is now deprecated. With Ant you get the job done in 10% of the time. And it doesn’t take your entire dev team to read a Maven book. Even Ant has it’s drawbacks: programming in XML is the first, and programming in a declarative language (no loops, variables, real if/elses) is the second. For me Maven is out of question, and what remains is a decision between bash script and Ant. At the end of the day, all we want is to fire up the compiler and junit, archive and move some files around and perform some trivial edits in text files. If that task takes a monster like Maven, something is dead wrong.

]]>