buildr 1.4.2-x86-mswin32 → 1.4.3-x86-mswin32

data/CHANGELOG

@@ -1,3 +1,29 @@
+1.4.3 (2010-10-13)
+* Added:  BUILDR-514 New 'run' local task. http://buildr.apache.org/more_stuff.html#run
+* Added:  BUILDR-518 Load _buildr.rb or .buildr.rb from same directory as Buildfile
+          if they exist (Peter Donald)
+* Added:  BUILDR-519 Load repositories.release_to from build settings (Peter Donald)
+* Fixed:  BUILDR-520 Scaladoc 2.8 no longer support -windowtitle, use -doc-title instead.
+* Fixed:  BUILDR-512 Buildr::Util.ruby invokes non existent method (Peter Donald)
+* Fixed:  BUILDR-513 --trace fails with NoMethodError : undefined method
+          `include?' for nil:NilClass
+* Fixed:  BUILDR-515 -update-snapshot doesn't work as expected
+* Fixed:  BUILDR-517 package(:jar).include(directory, :as=>"foo") produces a corrupted jar
+* Fixed:  BUILDR-524 Optimized and more robust reading of jar MANIFEST.MF (Hugues Malphettes)
+* Fixed:  BUILDR-525 Documentation refers to repositories.upload_to rather than
+          repositories.release_to (Peter Donald)
+* Fixed:  BUILDR-526 Gracefully handle h2 sections with no id in documentation (Peter Donald)
+* Fixed:  BUILDR-527 package(:war) if libs passed are files (instead of artifacts)
+* Fixed:  BUILDR-528 Stop using deprecated method Gem::Dependency.version_requirements correctly (Peter Donald)
+* Fixed:  BUILDR-529 Stop using gem name "foo" in tests as it is the name of an actual gem (Peter Donald)
+* Fixed:  BUILDR-531 Improve error message when build requires gem that can't be found in local/remote 
+          gem repositories (Peter Donald)
+* Fixed:  BUILDR-532 package_as_source does not package resources (Tammo van Lessen)
+* Fixed:  BUILDR-534 package_with_sources does not package source artifacts if no sources but resources exist.
+          (Tammo Van Lessen)
+* Fixed:  BUILDR-535 Failing "checks" produce no meaningful errors  on JRuby
+* Fixed:  JavaRebel was previously not correctly detected.
+
 1.4.2 (2010-09-18)
 * Added:  BUILDR-415 Ability to exclude tests from command line
 * Added:  BUILDR-495 Document twitter on Buildr's homepage
@@ -42,10 +68,10 @@
 * Fixed:  BUILDR-482 Javadoc : cannot load class java.com.sun.tools.javadoc.Main
 * Fixed:  BUILDR-488 artifact poms not reinstalled
 * Fixed:  BUILDR-491 sftp download goes into infinite loop
-* Fixed:  BUILDR-498 Artifact download fails with "negative argument" if 
+* Fixed:  BUILDR-498 Artifact download fails with "negative argument" if
           terminal capabilities are undefined
-* Fixed:  BUILDR-499 Java package caching through constants 
-          e.g. (Java.java.lang.String cached as Java::Lang::String) 
+* Fixed:  BUILDR-499 Java package caching through constants
+          e.g. (Java.java.lang.String cached as Java::Lang::String)
           can shadow Ruby modules
 * Fixed:  BUILDR-501 Fix buildr label when listing tasks (Peter Donald)
 * Fixed:  BUILDR-503 Include with as includes directories as files when the directory has the same name as the path

data/_jbuildr

@@ -19,6 +19,8 @@
 
 require 'rubygems'
 $LOAD_PATH << File.join(File.dirname(__FILE__), 'lib') << File.join(File.dirname(__FILE__), 'addon')
+
+require 'buildr/version'
 spec = Gem::Specification.load(File.join(File.dirname(__FILE__), 'buildr.gemspec'))
 # To avoid a warning about the version_requirements deprecation, we use this method inline.
 def version_required(gem_def)

data/buildr.gemspec

@@ -68,7 +68,7 @@ for those one-off tasks, with a language that's a joy to use.
   spec.add_dependency 'jruby-openssl',        '>= 0.7' if spec.platform.to_s == 'java'
   spec.add_development_dependency 'jekyll', '~> 0.6.2' unless spec.platform.to_s == 'java'
   spec.add_development_dependency 'sdoc'
-  spec.add_development_dependency 'rcov', '~>0.8' unless spec.platform.to_s == 'java'
+  spec.add_development_dependency 'rcov', '0.9.9' unless spec.platform.to_s == 'java'
   spec.add_development_dependency 'win32console' if spec.platform.to_s == 'x86-mswin32'
   spec.add_development_dependency 'jekylltask', '>= 1.0.2' unless spec.platform.to_s == 'java'
 end

data/doc/index.textile

@@ -46,21 +46,20 @@ So let's get started.  You can "read the documentation online":quick_start.html,
 
 h2(#news).  What's New
 
-New in Buildr 1.4.0:
-
-* Support for Scala 2.8 compiler-level change detection and dependency tracking
-* Continuous compilation
-* Support for Eclipse classpath variables to avoid absolute pathnames in generated .classpath
-* "buildr test=only" will only run tests explicitly specified on the command line (and ignore transitive test dependencies)
-* Generic documentation framework (we do doc, not just javadoc)
-* New "test:failed" task to execute only tests that failed during last run
-* Project extensions (before/after_define) now support dependency ordering similar to Rake
-* Support unzipping tar.gz files
-* ScalaTest now generates JUnit XML reports in addition to text files.
-* Support protocol buffer code generation
-* Tested against Windows and Ubuntu on JRuby and MRI (and experimenting with Rubinius)
-* Dependency upgrades such as Ant 1.8.0, JUnit 4.7, JMock 2.5.1, Cobertura 1.9.4.1, Scala Specs 1.6.2.1, ScalaCheck 1.6, ScalaTest 1.0.1
-* And 60+ bug fixes !
+New in Buildr 1.4.2:
+
+* Added:  BUILDR-212 Update support for SNAPSHOT artifacts
+* Added:  BUILDR-465 Eclipse project names should be customizable
+* Added:  BUILDR-493 Eclipse task should generate javadocpath
+* Added:  BUILDR-509 Option to generate non-prefixed Eclipse project names
+* Added:  BUILDR-510 Add support for trace categories: --trace=foo,bar
+* Change: BUILDR-484 Upgrade to Scala 2.8.0 (final) and associated dependencies (ScalaCheck 1.7, ScalaTest 1.2, Specs 1.6.5)
+* Change: BUILDR-487 package :sources should default to using .jar extension (instead of .zip)
+* Fixed:  BUILDR-143 Upload to a file:// path needs ability to specify permissions
+* Fixed:  BUILDR-144 Filter does not preserve file permissions
+* Fixed:  BUILDR-203 Compiler guessing parses the source files.
+* Fixed:  BUILDR-317 Contribution of the integration with the ecj compiler
+* And 50+ bug fixes !
 
 See the "CHANGELOG":CHANGELOG for full details.
 

data/doc/more_stuff.textile

@@ -108,7 +108,7 @@ If you don't know which tracing category you need to enable or if you want a ful
 $ buildr --trace=all
 {% endhighlight %}
 
-h3. JavaRebel Integration
+h3(#javarebel). JavaRebel Integration
 
 "JavaRebel":http://www.zeroturnaround.com/javarebel is a live bytecode reloading solution by Zero Turnaround.  It's a lot like the hot code reload feature found in many Java IDE debuggers (like Eclipse and IntelliJ), but capable of handling things like member addition or removal and new class definition.  The tool itself is commercial and works with any JVM language, but they do offer a free license for use with Scala classes only.
 
@@ -146,6 +146,59 @@ scala> </pre>
 
 Note that Buildr does *not* check to make sure that you have a valid JavaRebel license, so you may end up launching with JavaRebel configured but without the ability to use it (in which case, JavaRebel will print a notification).
 
+h2(#run). Running Your Application
+
+The @run@ task lets you easily run programs from your buildfile, such as launching your own application.
+
+In its simplest form, you simply define the main class of your Java application,
+
+{% highlight ruby %}
+define 'my-project' do
+  compile.with COMMONS_IO, HTTPCLIENT
+  run.using :main => "org.example.Main"
+end
+{% endhighlight %}
+
+And then run,
+
+{% highlight ruby %}
+~/my-project$ buildr run
+{% endhighlight %}
+
+which would launch your application using the project's compile classpath.
+
+It's also possible to pass arguments to the JVM using the @:java_args@ option:
+
+{% highlight ruby %}
+  run.using :main => "org.example.Main",
+            :java_args => ["-server"]
+{% endhighlight %}
+
+If your application requires arguments, you can pass in an array of values for the @:main@ option, or provide a set of system properties using @:properties@.
+
+{% highlight ruby %}
+  run.using :main => ["org.example.Main", "-t", "input.txt"],
+            :properties => { :debug => "true" }
+{% endhighlight %}
+
+The @run@ task is a local task, which means that Buildr will automatically pick the @run@ task matching the project in the current directory.  Executing the following command:
+
+{% highlight ruby %}
+~/my-project/subproject$ buildr run
+{% endhighlight %}
+
+will run the @my-project:subproject:run@ task, assuming @my-project@ is your top-level project.
+
+Here is a summary of @run.using@ options,
+
+|_. Option |_. Description ... |
+| @:main@   | The java main class, e.g. "com.example.Main". Can also be an array if the main class requires arguments. |
+| @:properties@   | A hash of system properties to be passed to java. |
+| @:java_args@ | An array of additional parameters to pass to java |
+| @:classpath@   | An array of additional classpath elements (i.e. artifacts, files, etc.). By default, the @run@ task automatically uses the @compile.dependencies@, @test.dependencies@ and @test.compile.target@ of your project. |
+
+p(note). The @run@ task also detects and uses JavaRebel if it's available.  See the "JavaRebel":#javarebel section for details.
+
 h2(#gems).  Using Gems
 
 The purpose of the buildfile is to define your projects, and the various tasks and functions used for building them.  Some of these are specific to your projects, others are more general in nature, and you may want to share them across projects.

data/doc/releasing.textile

@@ -1,12 +1,11 @@
 ---
 layout: default
-title: Releasing 
+title: Releasing
 ---
 
-Now that we built and test awesome software, let's the world know and release it.
+Now that we built and tested our awesome software, let's tell the world and release it.
 
-
-Each buildile can specify the current version with a constant named VERSION_NUMBER or THIS_VERSION.
+Each buildfile can specify the current version with a constant named @VERSION_NUMBER@  or @THIS_VERSION@.
 
 {% highlight ruby %}
 THIS_VERSION = "1.0.0-SNAPSHOT"
@@ -22,14 +21,14 @@ end
 
 h2(#default). What does a release do?
 
-The default behavior of the Release task is the following:
+The default behavior of the @Release@ task is the following:
 # Check that the version to be released and the next version are different
 # Check that the project is being tracked by Git or Subversion
-# Package, test and deploy the artifacts using THIS_VERSION value minus the '-SNAPSHOT' suffix (if any)
+# Package, test and deploy the artifacts using @THIS_VERSION@ value minus the @-SNAPSHOT@ suffix (if any)
 # Tag the repository with the released version number
-# Update the value of THIS_VERSION in the buildfile with the next version number
+# Update the value of @THIS_VERSION@ in the buildfile with the next version number
 
-Buildr will increment the last digit of the 3-digit versioni number if THIS_VERSION contains '-SNAPSHOT'. 
+Buildr will increment the last digit of the 3-digit versioni number if @THIS_VERSION@ ends with @-SNAPSHOT@.
 So, at the end of a release, the buildfile now looks like this:
 
 {% highlight ruby %}
@@ -55,11 +54,11 @@ dd35015  (tag: 1.0.0) Changed version number to 1.0.0
 
 h2(#custom_version). How to specify my own version number scheme?
 
-If THIS_VERSION does not contain '-SNAPSHOT', Buildr delegates the resolution of the next version number to the user which has 2 differents ways to express her wishes: Release.next_version or the environment variable NEXT_VERSION.
+If @THIS_VERSION@ does not contain @-SNAPSHOT@, Buildr delegates the resolution of the next version number to the user which has 2 differents ways to express her wishes: @Release.next_version@ or the environment variable @NEXT_VERSION@.
 
 h3(#next_version_proc). Using Release.next_version
 
-The Release class can receive the next version of the buildfile. This could be a string or a proc that would receive the current version and return the next version.
+The @Release@ class can receive the next version of the buildfile. This could be a string or a proc that would receive the current version and return the next version.
 
 {% highlight ruby %}
 THIS_VERSION = "1.0.0-SNAPSHOT"
@@ -69,7 +68,7 @@ Release.next_version = "2.0.0-SNAPSHOT"
 
 # or a proc
 Release.next_version = lambda do |this_version| # 1.0.0-SNAPSHOT
-    new_version = this_version.split(/\./)
+    new_version = @THIS_VERSION@.split(/\./)
     new_version[0] = new_version[0] + 1
     new_version
 end
@@ -85,17 +84,20 @@ end
 
 h3(#next_version_envvar). Using the environment variable NEXT_VERSION
 
-If the environment variable NEXT_VERSION is set, Buildr will use this value to update THIS_VERSION at the end of the release.
+If the environment variable @NEXT_VERSION@ is set, Buildr will use this value to update @THIS_VERSION@ at the end of the release.
 
 For conveniency, this variable is case insensitive.
 
-So, all 3 following commands would generate the buildfile below:
+So, all 3 following commands will run a release with a custom new version:
+
 {% highlight sh %}
 $ buildr release next_version="1.0.0-rc1"
 $ env next_version="1.0.0-rc1" buildr release
 $ env NEXT_VERSION="1.0.0-rc1" buildr release
 {% endhighlight %}
 
+Those commands will generate the Buildfile below:
+
 {% highlight ruby %}
 THIS_VERSION = "1.0.0-rc1"
 
@@ -107,10 +109,9 @@ define 'killer-app' do
 end
 {% endhighlight %}
 
-The environment variable NEXT_VERSION has precedence over Release.next_version.
-
+The environment variable @NEXT_VERSION@ has precedence over Release.next_version.
 
 h2(#custom_tag_and_msg). How to specify my own tag name and commit message?
 
-As explained earlier, Buildr will create two new commits and a new tag in the version control system. Similarly to Release.next_version, the commit message and the tag name can be customized with Release.message and Release.tag_name. Both could be strings or procs that would receive the released version i.i THIS_VERSION without '-SNAPSHOT'.
+As explained earlier, Buildr will create two new commits and a new tag in the version control system. Similarly to @Release.next_version@, the commit message and the tag name can be customized with @Release.message@ and @Release.tag_name@. Both could be strings or procs that would receive the released version @THIS_VERSION@ without @-SNAPSHOT@.
 

data/doc/settings_profiles.textile

@@ -54,8 +54,8 @@ p(note). Buildr does not check any of the arguments in @JAVA_OPTS@.  A common mi
 Some extensions may use additional environment variables, and of course, you can always add your own.  This example uses two environment variables for specifying the username and password:
 
 {% highlight ruby %}
-repositories.upload_to[:username] = ENV['USERNAME']
-repositories.upload_to[:password] = ENV['PASSWORD']
+repositories.release_to[:username] = ENV['USERNAME']
+repositories.release_to[:password] = ENV['PASSWORD']
 {% endhighlight %}
 
 
@@ -77,7 +77,7 @@ repositories:
   local: some/path/to/my_repo
 
   # prefer the local or nearest mirrors
-  remote: 
+  remote:
    - https://intra.net/maven2
    - http://example.com
 
@@ -86,8 +86,8 @@ repositories:
     username: john
     password: secret
 
-# You can place settings of your own, and reference them 
-# on buildfiles. 
+# You can place settings of your own, and reference them
+# on buildfiles.
 im:
   server: jabber.company.com
   usr: notifier@company-jabber.com
@@ -113,7 +113,7 @@ They help keep the buildfile and build.yaml file simple and readable, working to
 
 {% highlight yaml %}
 # This project requires the following ruby gems, buildr addons
-gems: 
+gems:
   # Suppose we want to notify developers when testcases fail.
   - buildr-twitter-notifier-addon >=1
   # we test with ruby mock objects
@@ -132,11 +132,11 @@ twitter:
   notify:
     test_failure: unless-modified
     compile_failure: never
-  developers: 
+  developers:
     - joe
     - jane
 
-jira: 
+jira:
   uri: https://jira.corp.org
 {% endhighlight %}
 
@@ -145,7 +145,7 @@ When buildr is loaded, required ruby gems will be installed if needed, thus addi
 Artifacts defined on @build.yaml@ can be referenced on your buildfile by supplying the ruby symbol to the @Buildr.artifact@ and @Buildr.artifacts@ methods.  The @compile.with@, @test.with@ methods can also be given these names.
 
 {% highlight ruby %}
-define 'my_project' do 
+define 'my_project' do
   compile.with artifacts(:log4j, :j2ee)
   test.with :spring, :j2ee
 end
@@ -154,7 +154,7 @@ end
 Build settings can be retreived using the @Buildr.settings.build@ accessor.
 
 {% highlight ruby %}
- task 'create_patch' do 
+ task 'create_patch' do
    patch = Git.create_patch :interactive => true
    if patch && agree("Would you like to request inclusion of #{patch}")
      jira = Jira.new( Buildr.settings.build['jira']['uri'] )  # submit a patch
@@ -174,8 +174,8 @@ Here's an example @buildr.rb@:
 
 {% highlight ruby %}
 # Only I should know that
-repositories.upload_to[:username] = 'assaf'
-repositories.upload_to[:password] = 'supersecret'
+repositories.release_to[:username] = 'assaf'
+repositories.release_to[:password] = 'supersecret'
 # Search here first, it's faster
 repositories.remote << 'http://inside-the-firewall'
 {% endhighlight %}
@@ -212,7 +212,7 @@ Here's a simple example for handling different environments within the Buildfile
 
 {% highlight ruby %}
 project 'db-module' do
-  db = (environment == 'production' ? 'oracle' : 'hsql')
+  db = (Buildr.environment == 'production' ? 'oracle' : 'hsql')
   resources.from(_("src/main/#{db}"))
 end
 {% endhighlight %}

data/lib/buildr.rb

@@ -22,6 +22,7 @@ require 'buildr/packaging'
 require 'buildr/java'
 require 'buildr/ide'
 require 'buildr/shell'
+require 'buildr/run'
 
 # 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.rb

@@ -23,6 +23,7 @@ require 'buildr/core/filter'
 require 'buildr/core/compile'
 require 'buildr/core/test'
 require 'buildr/core/shell'
+require 'buildr/core/run'
 require 'buildr/core/checks'
 require 'buildr/core/transports'
 require 'buildr/core/generate'

data/lib/buildr/core/application.rb

@@ -346,9 +346,7 @@ module Buildr
         ['--trace', '-t [CATEGORIES]', "Turn on invoke/execute tracing, enable full backtrace.",
           lambda { |value|
             options.trace = true
-            if value
-              options.trace_categories = value.split(',').map { |v| v.downcase.to_sym }
-            end
+            options.trace_categories = value ? value.split(',').map { |v| v.downcase.to_sym } : []
             options.trace_all = options.trace_categories.include? :all
             verbose(true)
           }
@@ -469,12 +467,19 @@ module Buildr
       if File.exist?(old) && !File.exist?(new)
         warn "Deprecated: Please move buildr.rb from your home directory to the .buildr directory in your home directory"
       end
+
       # Load home/.buildr/buildr.rb in preference
       files = [ File.exist?(new) ? new : old, 'buildr.rb' ].select { |file| File.exist?(file) }
       files += [ File.expand_path('buildr.rake', ENV['HOME']), File.expand_path('buildr.rake') ].
         select { |file| File.exist?(file) }.each { |file| warn "Please use '#{file.ext('rb')}' instead of '#{file}'" }
       files += (options.rakelib || []).collect { |rlib| Dir["#{rlib}/*.rake"] }.flatten
 
+      # Load .buildr/_buildr.rb same directory as buildfile
+      %w{.buildr.rb _buildr.rb}.each do |f|
+        local_buildr = File.expand_path("#{File.dirname(Buildr.application.buildfile.to_s)}/#{f}")
+        files << local_buildr if File.exist?( local_buildr )
+      end
+
       files.each do |file|
         unless $LOADED_FEATURES.include?(file)
           load file