buildr 1.4.7-x86-mswin32 → 1.4.8-x86-mswin32

data/doc/download.textile

@@ -20,6 +20,30 @@ The source code is included in both source and binary distribution, the Gem dist
 
 h2(#dist).  Binaries and Source Code
 
+h3. buildr 1.4.8 (2012-11-01)
+
+|_. Package |_. MD5 Checksum |_. PGP |
+| "buildr-1.4.8-java.gem":http://www.apache.org/dyn/closer.cgi/buildr/1.4.8/buildr-1.4.8-java.gem | "68679f89f7e0f90bb4446965d1184e0a":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8-java.gem.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8-java.gem.asc |
+| "buildr-1.4.8-x86-mswin32.gem":http://www.apache.org/dyn/closer.cgi/buildr/1.4.8/buildr-1.4.8-x86-mswin32.gem | "40abdb4c2ff2bb7232822198e6882ee0":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8-x86-mswin32.gem.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8-x86-mswin32.gem.asc |
+| "buildr-1.4.8.gem":http://www.apache.org/dyn/closer.cgi/buildr/1.4.8/buildr-1.4.8.gem | "0e92c281a59d3fc475f1a0184200a70f":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8.gem.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8.gem.asc |
+| "buildr-1.4.8.tgz":http://www.apache.org/dyn/closer.cgi/buildr/1.4.8/buildr-1.4.8.tgz | "f19029a7dba62917978b42652328bf6c":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8.tgz.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8.tgz.asc |
+| "buildr-1.4.8.zip":http://www.apache.org/dyn/closer.cgi/buildr/1.4.8/buildr-1.4.8.zip | "8a484f5ec930eba0b93fe9079fd41079":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8.zip.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.8/buildr-1.4.8.zip.asc |
+
+p>. ("Release signing keys":http://www.apache.org/dist/buildr/1.4.8/KEYS)
+
+
+h3. buildr 1.4.7 (2012-05-29)
+
+|_. Package |_. MD5 Checksum |_. PGP |
+| "buildr-1.4.7-x86-mswin32.gem":http://www.apache.org/dyn/closer.cgi/buildr/1.4.7/buildr-1.4.7-x86-mswin32.gem | "062031b8890b489673be814ca08598cb":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7-x86-mswin32.gem.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7-x86-mswin32.gem.asc |
+| "buildr-1.4.7-java.gem":http://www.apache.org/dyn/closer.cgi/buildr/1.4.7/buildr-1.4.7-java.gem | "a7cfac76a53fb6deaac0b12acc02a82c":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7-java.gem.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7-java.gem.asc |
+| "buildr-1.4.7.gem":http://www.apache.org/dyn/closer.cgi/buildr/1.4.7/buildr-1.4.7.gem | "85a8ddb9ae752e04c0416e2f1d30d064":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7.gem.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7.gem.asc |
+| "buildr-1.4.7.tgz":http://www.apache.org/dyn/closer.cgi/buildr/1.4.7/buildr-1.4.7.tgz | "576789cb7d10216cc3b7383441fd2596":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7.tgz.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7.tgz.asc |
+| "buildr-1.4.7.zip":http://www.apache.org/dyn/closer.cgi/buildr/1.4.7/buildr-1.4.7.zip | "e414f72706885a695a380693e9c530c7":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7.zip.md5 | "Sig":http://www.apache.org/dist/buildr/1.4.7/buildr-1.4.7.zip.asc |
+
+p>. ("Release signing keys":http://www.apache.org/dist/buildr/1.4.7/KEYS)
+
+
 h3. buildr 1.4.6 (2011-06-22)
 
 |_. Package |_. MD5 Checksum |_. PGP |

data/doc/index.textile

@@ -46,29 +46,49 @@ So let's get started.  You can "read the documentation online":quick_start.html,
 
 h2(#news).  What's New
 
-New in Buildr 1.4.6 (June 24th, 2011)
-
-* Added:  Support for Scala 2.9.0+ (with help of Alexis Midon)
-* Added:  BUILDR-592 Allow Users to Specify SSH Options for Deployment (Marc-André Laverdière)
-* Fixed:  BUILDR-591 IntelliJ Sort modules in iml files generated by idea task to ensure main_dependencies are exported
-* Fixed:  BUILDR-583 Update jruby install to use jruby version 1.6.1 (Alexis Midon)
-* Fixed:  BUILDR-582 Revert the name change for the task to generate Intellij project files to 'idea'
-* Change: BUILDR-579 Format generated IDEA project files to look more like what IntelliJ generates (Peter Royal)
-* Change: BUILDR-574 Enhance idea task to generate test resources with test scope (Jean-Philippe Caruana)
-* Change: BUILDR-576 Upgrade to JUnit 4.8.2
-* Change: Upgrade to JRuby 1.6.2
-* Change: Scala 2.9.0-1 is now default, along with ScalaCheck 1.9, ScalaTest 1.6.1 and Specs 1.6.8.
-* Change: ScalaCheck, ScalaTest and Specs now default to sane versions when using older Scala versions.
-* Fixed:  BUILDR-571 Generated IDEA projects include resources multiple times (Peter Royal)
-* Fixed:  BUILDR-573 HTTP upload PUT request with incorrect Content-Type (Mathias Doenitz)
-* Fixed:  BUILDR-578 Tar task does not preserve uid/gid on folders (Jean-Philippe Caruana)
-* Fixed:  BUILDR-251 Classifier not handled when downloading snapshot artifacts (Ryan Fowler)
-* Fixed:  BUILDR-585 "TypeError : can't dup NilClass" when merging jars
-* Fixed:  BUILDR-586 ScalaTest uses deprecated ant task (Martin Partel)
-* Fixed:  BUILDR-584 eclipse plugin should use absolute path
-* Fixed:  BUILDR-587 ScalaTest uses deprecated reporter parameters
-
-See the "CHANGELOG":CHANGELOG for full details.
+Highlights from Buildr 1.4.8 (Nov 11th, 2012)
+
+* Change: Revert to importing non-verbose FileUtils utility methods to match buildr 1.4.6 release and earlier.
+* Added:  Experimental support for jacoco code coverage tool.
+* Fixed:  BUILDR-655 - Support JDK1.7 under OSX
+* Change: Updated dependency versions;
+          - builder (3.1.3)
+          - rubyforge (2.0.4)
+          - net-ssh (2.6.0)
+          - hoe (3.1.0)
+          - rjb (1.4.2)
+          - rdoc (3.12)
+          - xml-simple (1.1.1)
+          - rspec-expectations (2.11.3)
+          - rspec-mocks (2.11.3)
+          - rspec-core (2.11.1)
+          - rspec (2.11.0)
+          - rubyzip (0.9.9)
+* Added:  BUILDR-652 Generate buildfile from Eclipse workspace. (Niklaus Giger)
+* Fixed:  BUILDR-627 Support explicitly listed source files in buildr cc task. (Christopher Tiwald)
+* Fixed:  BUILDR-606 Transitive artifact resolution should not include artifacts in 'provided' scope in poms to
+          match maven behaviour. (Julio Arias)
+* Change: BUILDR-640 Enable building jekyll and rdoc under more rubies. (Niklaus Giger)
+* Change: Mark Buildr:Bnd.remote_repository as deprecated as dependencies appear in maven central.
+* Added:  BUILDR-654 Add the ability to configure the version of BND used by bnd addon. (Niklaus Giger)
+* Added:  Create the git_auto_version addon that automatically specifies a version for a git project based
+          on git describe.
+* Added:  Integrate with Zinc (incremental compilation wrapper for scalac 2.9+)
+* Change: Default to Scala 2.9.2, ScalaTest 1.8, Scala Specs2 1.11,
+          ScalaCheck 1.10.0.
+* Change: Scala artifact repository changed to
+          http://oss.sonatype.org/content/repositories/releases
+* Added:  BUILDR-645 Support Mercurial as a version control system (Tan Quach)
+* Fixed:  BUILDR-646 TGZ files do not keep their permissions when extracted
+          via Buildr::Unzip#extract
+* Added:  Add add_exploded_ear_artifact and add_exploded_ejb_artifact to the idea project extension.
+* Change: Default to using Checkstyle 5.5 in the checkstyle addon.
+* Fixed:  Fix the add_exploded_war_artifact method on the idea project by adding in missing method
+          `partition_dependencies`.
+* Fixed:  Fix the extension of the gwt plugin so that it can be required as an addon.
+* Fixed:  Fix the undefined default_web_xml variable in the add_web_facet method on the idea project.
+
+This is a partial list -- see the "CHANGELOG":CHANGELOG for full details.
 
 h2(#notices).  Credits & Notices
 

data/doc/languages.textile

@@ -189,7 +189,7 @@ You may also determine the version in use by querying the @Scala.version@ attrib
 Scala.version       # => '2.8.0'
 {% endhighlight %}
 
-Regardless of how the Scala version is determined, if you have the same Scala version installed on your system and the SCALA_HOME environment variable points to it, then your local installation will be used.   Otherwise, Buildr will download it from the "Scala Tools repository":http://scala-tools.org/ which is automatically enlisted when you @require@ Scala.  The only drawback if you don't have a local installation is the FSC compiler won't be available.
+Regardless of how the Scala version is determined, if you have the same Scala version installed on your system and the SCALA_HOME environment variable points to it, then your local installation will be used.   Otherwise, Buildr will download it from the "Sonatype repository":http://oss.sonatype.org/content/repositories/releases which is automatically enlisted when you @require@ Scala.  The only drawback if you don't have a local installation is the FSC compiler won't be available.
 
 p(tip). For Mac users, if you have installed Scala via "MacPorts":http://www.macports.org/  Buildr will look in the
 @/opt/local/share/scala/@ directory if you have not set @SCALA_HOME@.
@@ -202,7 +202,7 @@ The Scala compiler looks for source files in the project's @src/main/scala@  dir
 Any Java source files found in the @src/main/java@ directory will be compiled using the Scala/Java joint compiler into the @target/classes@ directory.  Both the Java and the Scala sources are compiled with an inclusive classpath, meaning that you may have a Java class which depends upon a Scala class which depends upon a Java class, all within the same project.  The Java sources will be compiled with the same dependencies as the Scala sources with the addition of the @scala-library.jar@ file as required for Scala interop.
 
 Note that you cannot use the Groovy *and* the Scala joint compilers in the same project.  If both are required, the Groovy joint compiler will take precedence.
-+
+
 If you point the @compile@ task at any other source directory, it will use the  Scala compiler if any of these directories contains files with the extension @.scala@.  The joint compilation of Java sources may only be pointed at an alternative directory using the feature to redefine the @_(:src, :main, :java)@ path.
 
 When using the Scala compiler, if you don't specify the packaging type, it defaults to JAR.
@@ -218,18 +218,25 @@ The Scala compiler supports the following options:
 | @:target@       | Bytecode compatibility (e.g. '1.4'). |
 | @:warnings@     | Issue warnings when compiling.  True when running in verbose mode. |
 | @:javac@        | A hash of options passed to the @javac@ compiler verbatim. |
+| @:incremental@  | If true, enables incremental compilation using Zinc. |
 
 h4. Fast Scala Compiler
 
 You may use @fsc@, the Fast Scala Compiler, which submits compilation jobs to a  compilation daemon, by setting the environment variable @USE_FSC@ to @yes@. Note that @fsc@ _may_ cache class libraries -- don't forget to run @fsc -reset@ if  you upgrade a library.
 
+(Note @fsc@ is not compatible with @zinc@ incremental compilation.)
+
 h4. Rebuild detection
 
+*Scala 2.7*
+
 The Scala 2.7 compiler task assumes that each @.scala@ source file generates a  corresponding @.class@ file under @target/classes@ (or @target/test/classses@  for tests). The source may generate more @.class@ files if it contains more than one class, object, trait or for anonymous functions and closures.
 
 For example, @src/main/scala/com/example/MyClass.scala@ should generate at least @target/classes/com/example/MyClass.class@. If that it not the case, Buildr will always recompile your sources because it will assume this is a new source file that has never been compiled before.
 
-Fortunately, Scala 2.8 provides a substantially better interface for implementing change detection.  Whenever you use Scala 2.8 (see below), Buildr will auto-detect the version and enable this feature dynamically.  After the @compile@ task runs, the relevant target directory will contain a @.scala-deps@ file, generated by the Scala compiler.  The manner in which this file is used can be configured using the @:make@ compiler option.  The following values are available:
+*Scala 2.8*
+
+Scala 2.8 provides a substantially better interface for implementing change detection.  Whenever you use Scala 2.8 (see below), Buildr will auto-detect the version and enable this feature dynamically.  After the @compile@ task runs, the relevant target directory will contain a @.scala-deps@ file, generated by the Scala compiler.  The manner in which this file is used can be configured using the @:make@ compiler option.  The following values are available:
 
 * @:all@ - Disables compiler-level change detection
 * @:changed@ - Only build changed files without considering file dependencies
@@ -247,11 +254,49 @@ Effectively, this is telling the Scala compiler to ignore the information it has
 
 To avoid unusual behavior, compiler-level change detection is disabled whenever the joint Scala-Java compiler is used.  Thus, any @.java@ files in a project handled by the Scala compiler will cause the @:make@ option to be ignored and revert to the exclusive use of Buildr's change detection mechanism (as described above).
 
-h4. Scala 2.8
+*Scala 2.9 and later*
+
+Starting with Buildr 1.4.8, Buildr integrates with the "Zinc":https://github.com/typesafehub/zinc incremental compilation wrapper for @scalac@.  Incremental compilation can be enabled 3 ways,
+
+1) By setting the compiler's option directly,
+
+{% highlight ruby %}
+compile.using :incremental => true
+
+compile.options.incremental = true  # same as above
+{% endhighlight %}
 
-As of version 1.4, Buildr has *non-default* support for Scala 2.8.  If your @SCALA_HOME@ environment variable is pointing to an installation of Scala 2.8, then Buildr will use that compiler and enable 2.8-specific features.
+Note that this won't enable incremental compilation for both @compile@ and @test.compile@, you would have to set options on both.  For this reason, it's recommended that you set the option on the project instead (see below).
 
-As Scala 2.8 is currently pre-release, it is often desirable to maintain an installation of Scala 2.7 concurrently with Scala 2.8, defaulting to the former with the option to select the latter on a project-by-project basis.  This is most easily accomplished by setting @SCALA_HOME@ to point to the Scala 2.7 installation and @SCALA28_HOME@ to point to the Scala 2.8 installation.  With this configuration in place, Scala 2.8 can be selected for a specific project by dynamically reassigning @SCALA_HOME@ at the top of the buildfile (*before* @require 'buildr/scala'@):
+2) By setting the project's @scalac_options.incremental@,
+
+{% highlight ruby %}
+project.scalac_options.incremental = true
+{% endhighlight %}
+
+3) By setting the global @scalac.incremental@ option,
+
+in your @buildfile@:
+
+{% highlight ruby %}
+Buildr.settings.build['scalac.incremental'] = true
+{% endhighlight %}
+
+or in your @build.yaml@:
+
+{% highlight yaml %}
+scalac.incremental: true
+{% endhighlight %}
+
+h4. Support for different Scala versions
+
+Buildr defaults to the latest stable Scala version available at the time of the release if neither @SCALA_HOME@ nor the @scala.version@ build property are set.
+
+If your @SCALA_HOME@ environment variable points to an installation of Scala (2.7, 2.8, 2.9, ...), then Buildr will use that compiler and enable version-specific features.
+
+You may select the Scala version by dynamically in different ways,
+
+1) By reassigning @SCALA_HOME@ at the top of the buildfile (*before* @require 'buildr/scala'@):
 
 {% highlight ruby %}
 ENV['SCALA_HOME'] = ENV['SCALA28_HOME']
@@ -260,6 +305,20 @@ require 'buildr/scala'
 ...
 {% endhighlight %}
 
+2) By setting the @scala.version@ build property in your build.yaml file:
+
+{% highlight yaml %}
+scala.version: 2.9.1.RC1
+{% endhighlight %}
+
+3) By setting the @scala.version@ build property in your buildfile:
+
+{% highlight ruby %}
+require 'buildr/scala'
+...
+Buildr.settings.build['scala.version'] = '2.10-M6'
+{% endhighlight %}
+
 h3. Testing with Scala
 
 Buildr supports two main Scala testing frameworks:   "ScalaTest":http://www.artima.com/scalatest and  "Specs":http://code.google.com/p/specs/.  "ScalaCheck":http://code.google.com/p/scalacheck/ is also supported within the confines of either of these two frameworks.  Thus, your Specs may use ScalaCheck properties, as may your ScalaTest suites.

data/doc/more_stuff.textile

@@ -349,6 +349,8 @@ You can place this code inside @buildr.rb@ in the @.buildr@ directory under your
 
 h2(#eclipse). Eclipse
 
+h3. Use Apache Buildr to create Eclipse projects
+
 If you're using Eclipse, you can generate @.classpath@ and @.project@ from your Buildfile and use them to create a project in your workspace:
 
 {% highlight sh %}
@@ -379,6 +381,16 @@ end
 
 One more thing; these settings are inherited hierarchically so you may set them on a parent project if you want to share them across different projects.
 
+h3. Use Apache Buildr to create a buildfile from an Eclipse workspace
+
+If you're using Eclipse, you can generate a @buildfile@ from a directory which contains one (or more) Eclipse projects somewhere in its sub-directories.
+
+{% highlight sh %}
+$ buildr --generate /path/to/my_project
+{% endhighlight %}
+
+This creates a basic buildfile with a main project called 'my_project'. The buildfile contains a skeleton for compiling the Eclipse projects. If you want to automate dependency tracking via OSGi have a look at the "buildr4osgi":http://oss.intalio.com/buildr4osgi/ project. Support for building Eclipse RCP applications, running PDE tests and P2-sites is currently lacking in Buildr.
+
 h2(#idea). IntelliJ IDEA
 
 If you use IntelliJ IDEA, you can generate project files by issuing:

data/doc/packaging.textile

@@ -347,6 +347,8 @@ The bundle packaging format is included as an addon so the build file must expli
 require "buildr/bnd"
 
 repositories.remote << Buildr::Bnd.remote_repository
+# uncomment the next version to override the version of bnd
+# Buildr::Bnd.version = '0.0.384'
 
 define 'myProject' do
   ...

data/doc/settings_profiles.textile

@@ -166,7 +166,7 @@ Build settings can be retreived using the @Buildr.settings.build@ accessor.
 
 h2(#variable). Non constant settings
 
-Before loading the Buildfile, Buildr will attempt to load two other files: the @buildr.rb@ file in the @.buildr@ directory under your home directory, followed by the @buildr.rb@ file it finds in the build directory.
+Before loading the Buildfile, Buildr will attempt to load two other files: the @buildr.rb@ file in the @.buildr@ directory under your home directory, followed by the @_buildr.rb@ (or @.buildr.rb@) file it finds in the build directory.
 
 The loading order allows you to place global settings that affect all your builds in your @buildr.rb@, but also over-ride those with settings for a given project.
 

data/lib/buildr.rb

@@ -82,10 +82,6 @@ require 'buildr/java/doc'
 require 'buildr/java/deprecated'
 require 'buildr/ide/idea'
 require 'buildr/ide/eclipse'
-# Order is significant for auto-detection, from most specific to least
-require 'buildr/ide/eclipse/plugin'
-require 'buildr/ide/eclipse/scala'
-require 'buildr/ide/eclipse/java'
 
 # Methods defined in Buildr are both instance methods (e.g. when included in Project)
 # and class methods when invoked like Buildr.artifacts().

data/lib/buildr/core/application.rb

@@ -387,23 +387,31 @@ module Buildr
     end
 
     def ask_generate_buildfile
-      source = choose do |menu|
+      source, fromEclipse = choose do |menu|
         menu.header = "To use Buildr you need a buildfile. Do you want me to create one?"
-        menu.choice("From Maven2 POM file") { 'pom.xml' } if File.exist?('pom.xml')
-        menu.choice("From directory structure") { Dir.pwd }
-        menu.choice("Cancel") { }
+        menu.choice("From eclipse .project files") { [Dir.pwd, true] } if Generate.has_eclipse_project?
+        menu.choice("From Maven2 POM file") { ['pom.xml', false] } if File.exist?('pom.xml')
+        menu.choice("From directory structure") { [Dir.pwd, false] }
+        menu.choice("Cancel") {}
       end
       if source
-        buildfile = raw_generate_buildfile(source)
+        buildfile = raw_generate_buildfile(source, fromEclipse)
         [buildfile, File.dirname(buildfile)]
       end
     end
 
-    def raw_generate_buildfile(source)
+    def raw_generate_buildfile(source, fromEclipse=Generate.has_eclipse_project?)
       # We need rakefile to be known, for settings.build to be accessible.
       @rakefile = File.expand_path(DEFAULT_BUILDFILES.first)
       fail "Buildfile already exists" if File.exist?(@rakefile) && !(tty_output? && agree('Buildfile exists, overwrite?'))
-      script = File.directory?(source) ? Generate.from_directory(source) : Generate.from_maven2_pom(source)
+      script = nil
+      if fromEclipse
+        script = Generate.from_eclipse(source)
+      elsif File.directory?(source)
+        script = Generate.from_directory(source)
+      else
+        script = Generate.from_maven2_pom(source)
+      end
       File.open @rakefile, 'w' do |file|
         file.puts script
       end
@@ -593,7 +601,7 @@ end
 HighLine.use_color = false
 if $stdout.isatty
   begin
-    require 'Win32/Console/ANSI' if Config::CONFIG['host_os'] =~ /mswin|win32|dos|cygwin|mingw/i
+    require 'Win32/Console/ANSI' if RbConfig::CONFIG['host_os'] =~ /mswin|win32|dos|cygwin|mingw/i
     HighLine.use_color = true
   rescue LoadError
   end
@@ -689,3 +697,28 @@ module RakeFileUtils #:nodoc:
     EOS
   end
 end
+
+
+# It is unclear why this needs to be included on windows but it does seem to be needed.
+# But it can not be included under linux as it rewrites the install command
+if Buildr::Util.win_os?
+
+module Rake::DSL #:nodoc:
+  FileUtils::OPT_TABLE.each do |name, opts|
+    default_options = []
+    if opts.include?(:verbose) || opts.include?("verbose")
+      default_options << ':verbose => RakeFileUtils.verbose_flag == true'
+    end
+    next if default_options.empty?
+    module_eval(<<-EOS, __FILE__, __LINE__ + 1)
+    def #{name}( *args, &block )
+      super(
+        *rake_merge_option(args,
+          #{default_options.join(', ')}
+          ), &block)
+    end
+    EOS
+  end
+end
+
+end

data/lib/buildr/core/build.rb

@@ -100,6 +100,58 @@ module Buildr
 
   end
 
+  module Hg #:nodoc:
+    module_function
+
+    # :call-seq:
+    #   hg(*args)
+    #
+    # Executes a Mercurial (hg) command passing through the args and returns the output. 
+    # Throws exception if the exit status is not zero. For example:
+    #   hg 'commit'
+    #   hg 'update', 'default'
+    def hg(*args)
+      cmd = "hg #{args.shift} #{args.map { |arg| arg.inspect }.join(' ')}"
+      output = `#{cmd}`
+      fail "Mercurial command \"#{cmd}\" failed with status #{$?.exitstatus}\n#{output}" unless $?.exitstatus == 0
+      return output
+    end
+
+    # Return a list of uncommitted / untracked files as reported by hg status
+    # The codes used to show the status of files are:
+    #   M = modified
+    #   A = added
+    #   R = removed
+    #   C = clean
+    #   ! = missing (deleted by non-hg command, but still tracked)
+    #   ? = not tracked
+    #   I = ignored
+    #     = origin of the previous file listed as A (added)
+    def uncommitted_files
+      `hg status`.scan(/^(A|M|R|!|\?) (\S.*)$/).map{ |match| match.last.split.last }
+    end
+
+    # Commit the given file with a message. The file should already be added to the Mercurial index.
+    def commit(file, message)
+      hg 'commit', '-m', message, file
+    end
+
+    # Update the remote branch with the local commits
+    # This will push the current remote destination and current branch.
+    def push
+      hg 'push'
+    end
+
+    # Return the name of the current local branch or nil if none.
+    def current_branch
+      hg('branch').to_s.strip
+    end
+
+    # Return the aliases (if any) of any remote repositories which the current local branch tracks
+    def remote
+      hg('paths').scan(/^(?:default|default-push)\s+=\s+(\S.*)/).map{ |match| match.last }
+    end
+  end
 
   module Git  #:nodoc:
     module_function
@@ -415,6 +467,54 @@ module Buildr
   end
 
 
+  class HgRelease < Release
+    class << self
+      def applies_to?
+        if File.exist? '.hg/requires'
+          true
+        else
+          curr_pwd = Dir.pwd
+          Dir.chdir('..') do
+            return false if curr_pwd == Dir.pwd # Means going up one level is not possible.
+            applies_to?
+          end
+        end
+      end
+    end
+
+    # Fails if one of these 2 conditions are not met:
+    #   1. The reository is not 'clean'; no content staged or unstaged
+    #   2. The repository is only a local repository and has no remote refs
+    def check
+      super
+      info "Working in branch '#{Hg.current_branch}'"
+      uncommitted = Hg.uncommitted_files
+      fail "Uncommitted files violate the First Principle Of Release!\n#{uncommitted.join("\n")}" unless uncommitted.empty?
+      fail "You are releasing from a local branch that does not track a remote!" if Hg.remote.empty?
+    end
+
+    # Tag this release in Mercurial
+    def tag_release(tag)
+      unless this_version == extract_version
+        info "Committing buildfile with version number #{extract_version}"
+        Hg.commit File.basename(Buildr.application.buildfile.to_s), message
+        Hg.push if Hg.remote
+      end
+      info "Tagging release #{tag}"
+      Hg.hg 'tag', tag, '-m', "[buildr] Cutting release #{tag}"
+      Hg.push if Hg.remote
+    end
+
+    # Update buildfile with next version number
+    def update_version_to_next
+      super
+      info "Current version is now #{extract_version}"
+      Hg.commit File.basename(Buildr.application.buildfile.to_s), message
+      Hg.push if Hg.remote
+    end     
+  end
+
+
   class GitRelease < Release
     class << self
       def applies_to?
@@ -430,7 +530,7 @@ module Buildr
       end
     end
 
-    # Fails if one of theses 2 conditions are not met:
+    # Fails if one of these 2 conditions are not met:
     #    1. the repository is clean: no content staged or unstaged
     #    2. some remote repositories are defined but the current branch does not track any
     def check
@@ -491,6 +591,7 @@ module Buildr
     end
   end
 
+  Release.add HgRelease
   Release.add SvnRelease
   Release.add GitRelease