blob: 6028ded2164f4bda747744c8299ae67df0f50a37 [file] [log] [blame]
layout: default
title: Apache Buildr
Apache Buildr is a build system for Java-based applications, including support for Scala, Groovy and a growing number of JVM languages and tools. 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.
h2(#why). Why Buildr Rocks
"Daniel Spiewak":
bq. If you think about it, the question isn’t “Why use Buildr?”, it’s really “Why use anything else?” The advantages afforded by Buildr are so substantial, I really can’t see myself going with any other tool, at least not when I have a choice.
"Tristan Juricek":
bq. That’s still the strongest sell: it builds everything I need, and as I’ve needed more, I just got things working without a lot of fuss.
"Matthieu Riou":
bq. We used to rely on Ant, with a fairly extensive set of scripts. It worked but was expensive to maintain. The biggest mistake afterward was to migrate to Maven2. I could write pages of rants explaining all the problems we ran into and we still ended up with thousands of lines of XML.
"Martin Grotzke":
bq. The positive side effect for me as a java user is that I learn a little ruby, and that’s easy but lots of fun… :-)
"Ijonas Kisselbach":
bq. I've cleaned up & migrated the Vamosa build process from 768 lines of Ant build.xml to 28 lines of Buildr.
h2(#what). What You Get
* 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 builds what has changed since the last release.
* A drop-in replacement for Maven 2.0, Buildr uses the same file layout, artifact specifications, local and remote repositories.
* All your Ant tasks are belong to us! Anything you can do with Ant, you can do with Buildr.
* No overhead for building "plugins" or configuration. Just write new tasks or functions.
* 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?
So let's get started. You can "read the documentation online":quick_start.html, or "download the PDF":buildr.pdf.
h2(#news). What's New
Highlights from Buildr 1.5.8 (2019-07-14)
* Fixed: Add support for IntelliJ IDEAs external annotations.
* Added: Detect external annotations in the local project and add them to the generated IntelliJ IDEA
module when generating. The default location is `src/main/annotations` but other locations
can be specified by modifying the `project.iml.annotation_paths` property.
* Fixed: Explicitly specify the `:sourcepath` parameter for javadoc tool. This enables additional parameters
such as `-packagenames` and `-subpackages` to be passed to the underling tool.
* Fixed: Stop generating poms with the parent POM `org.sonatype.oss:oss-parent:8`. The las update was a long time
ago (i.e. 2012) and it is no longer maintained. It was also deprecated several years ago and is not
guaranteed to work in modern Maven deployments.
Highlights from Buildr 1.5.7 (2019-02-16)
* Fixed: The fix that allowed special characters in usernames and passwords was only partially applied
in the `1.5.6` release. The complete fix that correctly decoded usernames and passwords before
passing them to HTTP library is now been applied.
* Change: GWT Addon: Added support for `:skip_merge_gwt_dependencies` parameter that makes it possible to
avoid adding GWT dependencies to the project directly and thus the associated POM. This will be
required to support GWT3.x and GWT2.x simultaneously as well as making it easier to manage
dependencies in the POMs.
* Change: Javadoc: If the user does not supply an explicit `:sourcepath` to the doc/javadoc tool then
default the value to `project.compile.sources`. This will stop javadoc from scanning the classpath
for `*.java` files which can cause issues with projects that include `sources` classifier artifacts
on the classpath. This is particularly relevant for GWT based projects that include artifacts with
source embedded in the artifacts. This change also made it possible to remove an ugly hack in the
GWT addon that removed the gwt artifacts from the javadoc path.
* Change: Drop deprecated Gem::Specification#has_rdoc= (no replacement) method. Submitted by Olle Jonsson.
* Change: Use https protocol to access Gem metadata. Submitted by Olle Jonsson.
* Change: Change RSpec shared_context usage to avoid warnings. Submitted by Olle Jonsson.
This is a partial list -- see the "CHANGELOG":CHANGELOG for full details.
h2(#notices). Credits & Notices
! project of the Apache Software Foundation)!:
The Apache Software Foundation is a non-profit organization, consider "sponsoring": and check the "thanks": page.
"ColorCons":, copyright of Ken Saunders. "DejaVu fonts":, copyright of Bitstream, Inc.
Community member quotes from a thread on "Stack Overflow":
Developed with ! with RubyMine)!: