Buildr is a simple and intuitive build system for Java projects.
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.
- Compiling, copying and filtering resources, JUnit/TestNG test cases, APT source code generation, Javadoc and more.
- 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?
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.
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.
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.
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 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.
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).
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 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 firstname.lastname@example.org (see ). 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.
Subversion Directory: [WWW] https://svn.apache.org/repos/asf/incubator/buildr Issue Tracking: JIRA
- Assaf Arkin (Intalio)
- Alex Boisvert (Intalio)
- Matthieu Riou (Intalio)
- Yoav Shapira <yoavs at the usual for this wiki>
- Jim Jagielski <jim at somewhere around here or you should ask him>
- Matthieu Riou <mriou at apache.org>
The final destination is still uncertain. If Buildr is successful, a TLP could make sense. So right now we would like to ask the Incubator PMC to sponsor Buildr.