Author: assaf
Date: Mon Nov 26 23:14:36 2007
New Revision: 598536
URL: http://svn.apache.org/viewvc?rev=598536&view=rev
Log:
Fixed: Bunch of typos, courtesy of Merlyn Albery-Speyer and Soemirno
Kartosoewito.
Modified:
incubator/buildr/trunk/CHANGELOG
incubator/buildr/trunk/Rakefile
incubator/buildr/trunk/doc/pages/building.textile
incubator/buildr/trunk/doc/pages/contributing.textile
incubator/buildr/trunk/doc/pages/getting_started.textile
incubator/buildr/trunk/doc/pages/index.textile
incubator/buildr/trunk/doc/pages/more_stuff.textile
incubator/buildr/trunk/doc/pages/projects.textile
incubator/buildr/trunk/doc/pages/testing.textile
Modified: incubator/buildr/trunk/CHANGELOG
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/CHANGELOG?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/CHANGELOG (original)
+++ incubator/buildr/trunk/CHANGELOG Mon Nov 26 23:14:36 2007
@@ -2,6 +2,7 @@
* Changed: Resources sets permission on copied files to make them
read/write-able.
* Changed: Artifact download no longer generates destination directory if not
downloaded.
* Fixed: EOL in MANIFEST.MF.
+* Fixed: Bunch of typos, courtesy of Merlyn Albery-Speyer and Soemirno
Kartosoewito.
1.2.9 (11/8/2007)
* Changed: Upgraded to RJB 1.0.11.
Modified: incubator/buildr/trunk/Rakefile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/Rakefile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/Rakefile (original)
+++ incubator/buildr/trunk/Rakefile Mon Nov 26 23:14:36 2007
@@ -141,8 +141,7 @@
task :tag do |task|
cur_url = `svn info`.scan(/URL: (.*)/)[0][0]
- new_url = cur_url.sub(/trunk$/, "tags/#{spec.version.to_s}")
- system "svn", "remove", new_url, "-m", "Removing old copy" rescue nil
+ new_url = cur_url.sub(/(trunk$)|(branches\/\w*)$/,
"tags/#{spec.version.to_s}")
system "svn", "copy", cur_url, new_url, "-m", "Release
#{spec.version.to_s}"
end
end
Modified: incubator/buildr/trunk/doc/pages/building.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/building.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/building.textile (original)
+++ incubator/buildr/trunk/doc/pages/building.textile Mon Nov 26 23:14:36 2007
@@ -1,4 +1,4 @@
-h1. Building
+lding
To remove any confusion, Buildr's build task is actually called @[EMAIL
PROTECTED] It's also the default task that executes when you run @buildr@
without any task name.
@@ -173,7 +173,7 @@
The @build@ task runs the @compile@ (and @resources@) tasks as prerequisites,
followed by any actions you add to it, and completes by running the @test@
task. The @build@ task itself is a prerequisite to other tasks, for example,
@package@ and @[EMAIL PROTECTED]
-You can extend the @build@ task in two ways. You can add more prerequisite
that will execute before the task itself, or you can add actions that will
execute as part of the task. Which one you choose is up to you, we'll show you
how they differ in a second. If you call @build@ with a list of tasks, it adds
these tasks as prerequisites. Call @build@ with a block, and it adds that
block as an action. Again, a common idiom you'll see elsewhere in Buildr and
Rake.
+You can extend the @build@ task in two ways. You can add more prerequisites
that will execute before the task itself, or you can add actions that will
execute as part of the task. Which one you choose is up to you, we'll show you
how they differ in a second. If you call @build@ with a list of tasks, it adds
these tasks as prerequisites. Call @build@ with a block, and it adds that
block as an action. Again, a common idiom you'll see elsewhere in Buildr and
Rake.
Let's look at a simple example. Say we want to generate a Derby database form
an SQL file and include it in the ZIP package:
Modified: incubator/buildr/trunk/doc/pages/contributing.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/contributing.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/contributing.textile (original)
+++ incubator/buildr/trunk/doc/pages/contributing.textile Mon Nov 26 23:14:36
2007
@@ -3,7 +3,7 @@
Step 1, join the "mailing list":mailing_lists.html. It's the best place to
ask questions, report
"features", submit patches and let us know how you use Buildr in your own
projects.
-Step 2, checkout "Buildr from SVN":http://www.intalio.org/buildr:
+Step 2, checkout "Buildr from
SVN":http://svn.apache.org/repos/asf/incubator/buildr:
{{{!sh
$ svn co http://svn.apache.org/repos/asf/incubator/buildr/trunk buildr
Modified: incubator/buildr/trunk/doc/pages/getting_started.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/getting_started.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/getting_started.textile (original)
+++ incubator/buildr/trunk/doc/pages/getting_started.textile Mon Nov 26
23:14:36 2007
@@ -34,6 +34,16 @@
$ gem install buildr
}}}
+*Ubuntu:* Ubuntu is a popular Linux distribution. Here are specific
instructions for installing Buildr and its prerequisite packages on recent
versions of Ubuntu (Dapper, Edgy, Feisty and Gusty):
+
+{{{!sh
+$ sudo apt-get install ruby
+$ sudo apt-get install ruby1.8-dev
+$ sudo apt-get install build-essential
+$ sudo apt-get install libopenssl-ruby
+$ sudo gem install buildr
+}}}
+
*Linux and OS/X:* You probably need to be super user to install new Gems.
Turns out, in some configurations using @sudo@ does not pass the @JAVA_HOME@
environment variable, so either login as super user, or try this:
{{{
Modified: incubator/buildr/trunk/doc/pages/index.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/index.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/index.textile (original)
+++ incubator/buildr/trunk/doc/pages/index.textile Mon Nov 26 23:14:36 2007
@@ -7,7 +7,7 @@
* 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.
+* 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 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.
Modified: incubator/buildr/trunk/doc/pages/more_stuff.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/more_stuff.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/more_stuff.textile (original)
+++ incubator/buildr/trunk/doc/pages/more_stuff.textile Mon Nov 26 23:14:36 2007
@@ -23,7 +23,7 @@
You are, of course, describing your projects for the sake of those who will
maintain your code, right? To describe a project, or a task, call the @desc@
method before the project or task definition.
-h2. Peronsal Settings and Environment Variables
+h2. Personal Settings and Environment Variables
Some things clearly do not belong in the Buildfile. For example, the
username/password you use to upload releases. If you're working in a team or
making the source code available, you'd want to keep these in a separate place.
You may want to pick a different location for the local repository, or use a
different remote repository than everyone else, etc.
@@ -34,7 +34,7 @@
{{{!ruby
# Only I should know that
repositories.upload_to[:username] = "assaf"
-repositories.upload_to[:password] = "supersekreet"
+repositories.upload_to[:password] = "supersecret"
# Search here first, it's faster
repositories.remote << "http://inside-the-firewall";
}}}
Modified: incubator/buildr/trunk/doc/pages/projects.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/projects.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/projects.textile (original)
+++ incubator/buildr/trunk/doc/pages/projects.textile Mon Nov 26 23:14:36 2007
@@ -162,7 +162,7 @@
$ buildr build
# switch to and test only teh-impl
-$ cd the-impl
+$ cd teh-impl
$ buildr test
# switch to and package only la-web
@@ -247,7 +247,7 @@
h2. Defining The Project
-The project definition itself gives you a lot of pre-canned tasks to start
with, but that's not enough to build a project. You need to specify what gets
built and how, whether it's the classpath dependencies to use, the packages you
want to create and so forth. You can configure existing tasks, extend them to
do additional work, and create new tasks. All that magic happens inside the
project definition block.
+The project definition itself gives you a lot of pre-canned tasks to start
with, but that's not enough to build a project. You need to specify what gets
built and how, which classpath dependencies to use, the packages you want to
create and so forth. You can configure existing tasks, extend them to do
additional work, and create new tasks. All that magic happens inside the
project definition block.
Since the project definition executes each time you run Buildr, you don't want
to perform any work directly inside the project definition block. Rather, you
want to use it to specify how different build task work when you invoke them.
Here's an example to illustrate the point:
@@ -290,7 +290,7 @@
*Blocks are closures* The project definition is also a closure, which can
reference variables from enclosing scopes. You can use that, for example, to
define constants, variables and even functions in your Buildfile, and reference
them from your project definition. As you'll see later on, in the
"Artifacts":#artifacts section, it will save you a lot of work.
*Projects are namespaces*
-While executing the project definition, Buildr switches the namespace to the
project name. If you define the task "do-this" inside the _teh-impl_ project,
the actual task name is "killer-app:teh-impl:do-this". Likewire, the @compile@
task is actually "killer-app:teh-impl:compile".
+While executing the project definition, Buildr switches the namespace to the
project name. If you define the task "do-this" inside the _teh-impl_ project,
the actual task name is "killer-app:teh-impl:do-this". Likewise, the @compile@
task is actually "killer-app:teh-impl:compile".
From outside the project you can reference a task by its full name, either
@task("foo:do")@ or @project("foo").task("do")@. If you need to reference a
task defined outside the project from within the project, prefix it with
"rake:", for example, @task("rake:globally-defined")@.
Modified: incubator/buildr/trunk/doc/pages/testing.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/testing.textile?rev=598536&r1=598535&r2=598536&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/testing.textile (original)
+++ incubator/buildr/trunk/doc/pages/testing.textile Mon Nov 26 23:14:36 2007
@@ -187,7 +187,7 @@
h2. Testing Your Build
-So you got the build running and all the tests pass, binaries are shipping
when you find out some glaring omissions. The license file is empty, the
localized messages for Japanese are missing, there are no CSS files are not
where you expect them to be. The fact is, some errors slip by unit and
integration tests. So how do we make sure the same mistake doesn't happen
again?
+So you got the build running and all the tests pass, binaries are shipping
when you find out some glaring omissions. The license file is empty, the
localized messages for Japanese are missing, the CSS files are not where you
expect them to be. The fact is, some errors slip by unit and integration
tests. So how do we make sure the same mistake doesn't happen again?
Each project has a @check@ task that runs just after packaging. You can use
this task to verify that your build created the files you wanted it to create.
And to make it extremely convenient, we introduced the notion of expectations.
@@ -241,7 +241,7 @@
All these matchers operate against a file task. If you run them against a
ZipTask (including JAR, WAR, etc) they can also check the contents of the ZIP
file. And as you can see in the examples above, you can also run them against
a path in a ZIP file, checking its contents as if it was a directory, or
against an entry in a ZIP file, checking the content of that file.
-*Note:* The @package@ method returns a package task based on packaging type,
identifier, group, version and classifier. The last four are inferred, but if
you create a package with different specifications (for example, you specify a
classifier) your checks much call @package@ with the same qualifying arguments
to return the very same package task.
+*Note:* The @package@ method returns a package task based on packaging type,
identifier, group, version and classifier. The last four are inferred, but if
you create a package with different specifications (for example, you specify a
classifier) your checks must call @package@ with the same qualifying arguments
to return the very same package task.
Buildr expectations are based on RSpec. Check the "RSpec
documentation":http://rspec.rubyforge.org/ if want to see all the supported
matchers, or want to write your own.
