10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
When Ruby Builds Faster Than Java: Buildr
Posted by Sebastien Auvray on May 07, 2007
The Java build system Maven 1.0 was released 3 years ago and has been widely adopted in the open source world and in the industry; Since then, the 2.0 new releases haven't been met with quite the same level of approval. At the same time, Ruby has become more and more popular, and the concept of internal DSL has proved to be very effective with tools such as Rake.
On the other hand, DSLs written in generic languages just work. You get the simplicity of the high level language with the ability to extend it as far as computers can compute.
Over time, entirely new build systems have been written in Ruby, such as Bake and Rant. Others extend Rake, such as Raven, which supports external repository ala Maven.
The new kid on the block, Buildr, is aimed specifically at simplifying Java builds. Author Assaf Arkin advocates simplicity over xmlized and over-engineered solutions -- you can figure that from his blog or the tumblr quotes he collects. It's why he tried to get rid of Maven 2 in his projects like Apache Ode.
We quickly dubbed it the Maven Uncertainty Principle, though in fairness we knew there was little uncertainty or doubt whether the build will work: it won't. Finally, one day we just had enough. The test cases stopped working. (...) Either way, we had to choose. Agile or Maven. One of them will have to go.
Assaf wondered about a return to Ant:
So we started imagining the happy life we could all live with Maven out of the way. Maybe we'll switch back to Ant? For all its shortcomings, at least Ant builds work. Sure, Ant is not "declarative", the holy grail of software developers everywhere. But declarative done badly is worse than any imperative spaghetti code.
...and finally land on Rake.
So we did it. We started with Rake. Let me spoil the surprise for you. It turned out to be an excellent choice. Rake was a good start, but not what we'd hope for. The typical Java application we work on consists of several modules, all of which have the same common lifecycle tasks: compile, test, package, deploy. Writing those over and over for each and every module would make it not much better than Ant. There's got to a a better way.
The saga resulted in the birth of Buildr, which comes with handy goals (ie to handle xmlbeans), and let you rely on usual Ruby code to complete basic tasks.
The performance could have been the last stopper for a wider adoption but the "Fast and Furious" Buildr proved it could compete with Maven.
We're building the same code, running the same tests, compiling the same XMLBeans, creating the same Hibernate schemas, sharing the same remote and local repositories. All this to say, they're black box equivalent. Feed them the same project, and they generate the same JARs, WARs and distro files.
It builds the same except that the scripts have been downsized by 91% from 52 XML abused files to 1 script. But that's not all, Buildr managed to cut the build time by 50%! Even on partial builds, Buildr performs similarly or better than Maven.
Of course, we're not measuring raw Ruby against pure Java. We're comparing one implementation against another, where they both do the same thing. Black box equivalent. That's a real life benchmark.
Assaf ends with a nice conclusion:
Ruby might be slow, but what you build with it can be devilish fast.
We think it would be interesting to see how Maven and Buildr perform head-to-head.
The documentation is currently limited to RDoc and an Apache Rakefile example, but a complete guide is in progress.
RelatedVendorContent
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
SCM best practices for multiple processes, releases & distributed teams
A Guide to Branching and Merging Patterns
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
So?
by
Jakob Vad Nielsen
Posted
Re: So?
by
Sebastien Auvray
Posted
Not surprised
by
Thom Nichols
Posted
-
New ideas are always welcome. And Buildr is no exception. I'm am sure that it performs better than maven in the tests. If it can replace maven without any problems it's cool. But what about integration into common IDE's? What about proper documentation? What about the fact that Java programmers can make java plugins, ruby plugins, groovy plugins (soon) in maven? What about the fact that a common build solution will save companies from teaching consultatnts++ new build systems? Speed is always an issue, and should be. But as far as I know contributions to the Maven project is welcome in order to speed things up. If not, then Maven will die sooner or later anyway. I like the idea of a "real" language in my build config. But I think that Buildr will have to deliver much more than speedy build to convience me to switch.
-
I can't say I'm surprised. Maven seems to be quite a beast. If they're replacing XML POMs with Ruby scripts, I'm not surprised that Ruby parsing & execution would be faster than XML parsing + Java execution.
Obviously the most important point is if Buildr can use existing Maven plugins, then you might have a winner.
Maven relies heavily on Plexus, which as I understand is something like an IoC container (probably to handle the plugin architecture). I imagine that's where a lot of the slowness comes from.
In Groovy they are currently able to write Maven plugins. Now if they created a Maven POM builder in Groovy - that would be complete interoperability with Maven. That would be cool. -
But what about integration into common IDE's? What about proper documentation?
You're perfectly right, but well Buildr is a few week old baby.What about the fact that Java programmers can make java plugins, ruby plugins, groovy plugins (soon) in maven?
Well, as far as you go out of the maven2 schema, you have to write plugins, and they aren't as easily developed... Zillions of plugins is not really the solution to handle special cases.What about the fact that a common build solution will save companies from teaching consultatnts++ new build systems?
Well the interaction of developers with the build systems should be limited anyway: only extending it, with new libs, new file, new tasks... So once they know how the build system works (and Buildr uses generic concepts), the basic extensions can be written with few lines of script in a small learning curve language. And the more complex one will be handled by plugins. Concerning "common build systems", what about Maven itself when it switched from v1 to v2 ? Didn't the consultant needed to learn again ?... At the end this no real argument.But I think that Buildr will have to deliver much more than speedy build to convience me to switch.
Agree on that one, it should come with time and adoption.
3 comments
Watch Thread Reply