Abstract

Buildr is a simple and intuitive build system for Java projects.

Proposal

Buildr is a build system for Java applications. We wanted something that’s simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that’s a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management.

Here’s what we got:

A simple way to specify projects, and build large projects out of smaller sub-projects.

Pre-canned tasks that require the least amount of configuration, keeping the build script DRY and simple.

A dependency mechanism that only build that which changed since the last release.

Buildr uses the same file layout, artifact specifications, local and remote repositories as Maven 2.

All your Ant tasks belong to us! Anything you can do with Ant, you can do with Buildr.

Buildr is Ruby all the way down. No one-off task is too demanding when you write code using variables, functions and objects.

Simple way to upgrade to new versions.

Did we mention fast?

Background

Buildr is developed using the Ruby language and is layered on top of Rake, a popular build program for Ruby that provides all the task and task dependency infrastructure. It also relies on AntWrap to allow the reuse of all existing Ant tasks.

Rationale

Buildr's initial focus was to be layered on top of a powerful scripting language. It's an internal DSL and therefore enjoys a lot of ease of use and extensibility. It's also declarative, which gives scripts expressiveness (they're easy to read). And there's no XML!

We believe bringing Buildr at Apache is a good way to expand even more the build tool space, attract more committers and users to Buildr and have people start playing with the Ruby language, both within and outside the foundation.

Current Status

Meritocracy

Buildr has been mostly developed by Assaf Arkin but others have contributed either directly or through patches. In addition to contributed patches, work on Scala and JRuby is done by community members, and we're working to cultivate that and add more committers.

Community

A community of standard users but also power users is building around Buildr and several people are using it in all sort of different projects. Currently the discussion group has 86 members, more statistics available at http://groups.google.com/group/buildr-talk?lnk=srg

Core Developers

Core developers are mostly from a single organization but more and more power users are contributing patches and trying to extend Buildr. Also current core developers are very experienced in open source and already follow the Apache ways.

Alignment

Buildr is in line with the existing strong culture of build tools at Apache (Ant, Maven, Ivy, ...). It already relies on Maven2 repositories and follows most of its project structure conventions. It allows reuse of Ant tasks. Not to mention that other Apache projects could use it for their build (as ODE already does).

Known Risks

Orphaned Projects

Buildr core development is still very much dependent on Assaf but more and more people are getting familiar with the way Buildr works and its intricacies. So we're aware of the problem but also confident that we're on the right track as more and more people get involved.

Inexperience with Open Source

Many committers have experience working on open source projects. Three of them are Apache committers.

Reliance on Salaried Developers

Buildr is part of the committers job but is far from being the main company focus. So it's part working time and part personal time.

Relationships with Other Apache Products

As there aren't many Ruby projects in the ASF yet, there's less relationship possible for the time being. But Apache ODE is already using Buildr as its build tool.

Documentation & Intial Sources

External Dependencies

External dependencies are one of the main concerns that will need to be addressed. Buildr relies on several packages that are licensed under the Ruby License, which hasn't been categorized yet as okay or not. We've already mentioned this on legal-discuss@a.o (see [1]). There are a few subtleties as well as the Ruby packaging system, RubyGems, doesn't require you to distribute any dependencies as it handles them for you. So we will have to figure out what the options are before the first incubator release and graduation.