doc/index.textile - buildr - Git at Google

 ---
 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":http://www.codecommit.com/blog:

 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":http://tristanhunt.com/:

 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":http://offthelip.org/:

 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":http://www.javakaffee.de/blog/:

 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":http://twitter.com/ijonas/statuses/4134103928:

 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.6 (2018-05-10)
 * Fixed:  Ensure that the username and passwords declared for repositories are correctly url encoded for
           the upload repositories when converted to a URL. (i.e. Ensure `Buildr.repositories.release_to`
           and `Buildr.repositories.snapshot_to` settings can have usernames and passwords with special
           characters).
 * Added:  Add support for allowing some dependencies to include transitive dependencies via the
           `pom.include_transitive_dependencies` configuration setting.
 * Added:  Add support for adding dependencies to the pom via the `pom.additional_dependencies` configuration
           setting. These dependencies are `compile` scope and are in addition to any derived from the normal
           compile dependencies.
 * Fixed:  GWT Addon: Use version `1.0.2` of the `com.google.jsinterop:jsinterop-annotations:jar` artifact
           when using GWT 2.8.2 to align with version shipped with GWT.
 * Fixed:  Dependencies added as `pom.provided_dependencies` or `pom.runtime_dependencies` and not included
           as compile dependencies were incorrectly omitted from pom.
 * Fixed:  Dependencies added as `pom.provided_dependencies` and `pom.runtime_dependencies` were being
           incorrectly duplicated within the pom dependencies section. Now provided dependency scope takes
           precedence over runtime scoped dependency.
 * Fixed:  Dependencies added to POMs will specify the classifier unless it is the default value.
 * Added:  Add the `project.pom.dependency_filter` configuration property that can be set to a proc. The proc
           accepts a dependency and returns a boolean that determines whether the dependency is included in
           the generated pom or not.
 * Fixed:  POMs generated by Buildr use the parent pom `org.sonatype.oss:oss-parent:pom:7` but this
           generates a warning in the latest version of Maven. Modern versions of Maven would thus
           ignore transitive dependencies declared in the pom. The parent pom has now been upgraded
           to `org.sonatype.oss:oss-parent:pom:8` which will result in modern Maven correctly picking
           up transitive dependencies.
 * Change: JaCoCo Addon: Update JaCoCo version to 0.8.0 which in turns supports Java9.
 * Added:  GWT Addon: Added support for `:gwtc_args` parameter to supply arbitrary parameters to
           the GWT compiler.
 * Added:  Add support for sha512 digests to be generated for files during the upload. This is typically
           configured by adding `sha512` to the list of digests via a line such as:
           `repositories.release_to[:options] = {:digests => [:md5, :sha1, :sha512]}`
 * Fixed:  The default upload tasks would often get a ReadTimeout when uploading using http to a remote
           server that did not have `KeepAlive` socket option enabled and the upload took more than 60
           seconds (the default socket read timeout). Some commercial maven repositories could trigger
           this scenario during upload of even modest size artifacts. Default the read_timeout to 10 minutes
           when during upload to work address this issue.

 This is a partial list -- see the "CHANGELOG":CHANGELOG for full details.

 h2(#notices).  Credits & Notices

 !http://www.apache.org/images/asf-logo.gif(A project of the Apache Software Foundation)!:http://www.apache.org

 The Apache Software Foundation is a non-profit organization, consider "sponsoring":http://www.apache.org/foundation/sponsorship.html and check the "thanks":http://www.apache.org/foundation/thanks.html page.

 "ColorCons":http://www.mouserunner.com/Spheres_ColoCons1_Free_Icons.html, copyright of Ken Saunders.  "DejaVu fonts":http://dejavu.sourceforge.net, copyright of Bitstream, Inc.

 Community member quotes from a thread on "Stack Overflow":http://stackoverflow.com/questions/1015525/why-use-buildr-instead-of-ant-or-maven/1055864.

 Developed with !http://www.jetbrains.com/ruby/features/ruby_banners/ruby1/ruby120x30_white.gif(Developed with RubyMine)!:http://www.jetbrains.com/ruby/features?utm_source=RubyMineUser&utm_medium=Banner&utm_campaign=RubyMine
	---
	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":http://www.codecommit.com/blog:

	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":http://tristanhunt.com/:

	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":http://offthelip.org/:

	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":http://www.javakaffee.de/blog/:

	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":http://twitter.com/ijonas/statuses/4134103928:

	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.6 (2018-05-10)
	* Fixed: Ensure that the username and passwords declared for repositories are correctly url encoded for
	the upload repositories when converted to a URL. (i.e. Ensure `Buildr.repositories.release_to`
	and `Buildr.repositories.snapshot_to` settings can have usernames and passwords with special
	characters).
	* Added: Add support for allowing some dependencies to include transitive dependencies via the
	`pom.include_transitive_dependencies` configuration setting.
	* Added: Add support for adding dependencies to the pom via the `pom.additional_dependencies` configuration
	setting. These dependencies are `compile` scope and are in addition to any derived from the normal
	compile dependencies.
	* Fixed: GWT Addon: Use version `1.0.2` of the `com.google.jsinterop:jsinterop-annotations:jar` artifact
	when using GWT 2.8.2 to align with version shipped with GWT.
	* Fixed: Dependencies added as `pom.provided_dependencies` or `pom.runtime_dependencies` and not included
	as compile dependencies were incorrectly omitted from pom.
	* Fixed: Dependencies added as `pom.provided_dependencies` and `pom.runtime_dependencies` were being
	incorrectly duplicated within the pom dependencies section. Now provided dependency scope takes
	precedence over runtime scoped dependency.
	* Fixed: Dependencies added to POMs will specify the classifier unless it is the default value.
	* Added: Add the `project.pom.dependency_filter` configuration property that can be set to a proc. The proc
	accepts a dependency and returns a boolean that determines whether the dependency is included in
	the generated pom or not.
	* Fixed: POMs generated by Buildr use the parent pom `org.sonatype.oss:oss-parent:pom:7` but this
	generates a warning in the latest version of Maven. Modern versions of Maven would thus
	ignore transitive dependencies declared in the pom. The parent pom has now been upgraded
	to `org.sonatype.oss:oss-parent:pom:8` which will result in modern Maven correctly picking
	up transitive dependencies.
	* Change: JaCoCo Addon: Update JaCoCo version to 0.8.0 which in turns supports Java9.
	* Added: GWT Addon: Added support for `:gwtc_args` parameter to supply arbitrary parameters to
	the GWT compiler.
	* Added: Add support for sha512 digests to be generated for files during the upload. This is typically
	configured by adding `sha512` to the list of digests via a line such as:
	`repositories.release_to[:options] = {:digests => [:md5, :sha1, :sha512]}`
	* Fixed: The default upload tasks would often get a ReadTimeout when uploading using http to a remote
	server that did not have `KeepAlive` socket option enabled and the upload took more than 60
	seconds (the default socket read timeout). Some commercial maven repositories could trigger
	this scenario during upload of even modest size artifacts. Default the read_timeout to 10 minutes
	when during upload to work address this issue.

	This is a partial list -- see the "CHANGELOG":CHANGELOG for full details.

	h2(#notices). Credits & Notices

	!http://www.apache.org/images/asf-logo.gif(A project of the Apache Software Foundation)!:http://www.apache.org

	The Apache Software Foundation is a non-profit organization, consider "sponsoring":http://www.apache.org/foundation/sponsorship.html and check the "thanks":http://www.apache.org/foundation/thanks.html page.

	"ColorCons":http://www.mouserunner.com/Spheres_ColoCons1_Free_Icons.html, copyright of Ken Saunders. "DejaVu fonts":http://dejavu.sourceforge.net, copyright of Bitstream, Inc.

	Community member quotes from a thread on "Stack Overflow":http://stackoverflow.com/questions/1015525/why-use-buildr-instead-of-ant-or-maven/1055864.

	Developed with !http://www.jetbrains.com/ruby/features/ruby_banners/ruby1/ruby120x30_white.gif(Developed with RubyMine)!:http://www.jetbrains.com/ruby/features?utm_source=RubyMineUser&utm_medium=Banner&utm_campaign=RubyMine