Author: vborja
Date: Mon Feb 18 15:23:10 2008
New Revision: 628918
URL: http://svn.apache.org/viewvc?rev=628918&view=rev
Log:
Typo/Formatting fixes by Lacton
Modified:
incubator/buildr/trunk/doc/pages/artifacts.textile
incubator/buildr/trunk/doc/pages/building.textile
incubator/buildr/trunk/doc/pages/contributing.textile
incubator/buildr/trunk/doc/pages/extending.textile
incubator/buildr/trunk/doc/pages/more_stuff.textile
incubator/buildr/trunk/doc/pages/packaging.textile
incubator/buildr/trunk/doc/pages/projects.textile
Modified: incubator/buildr/trunk/doc/pages/artifacts.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/artifacts.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/artifacts.textile (original)
+++ incubator/buildr/trunk/doc/pages/artifacts.textile Mon Feb 18 15:23:10 2008
@@ -22,7 +22,7 @@
For example, @'org.apache.axis2:axis2:jar:1.2'@ refers to an artifact with
group identifier org.apache.axis2, artifact identifier axis2, a JAR file with
version 1.2. Classifiers are typically used to distinguish between similar
-file types, for example, a source distribution and binary distribution that
+file types, for example, a source distribution and a binary distribution that
otherwise have the same identifier and are both ZIP files.
@@ -103,7 +103,7 @@
}}}
When you use @require@, Ruby always looks for a filename with the @.rb@
-extension, so in this case if expects to find @artifacts.rb@ in the @shared@
+extension, so in this case it expects to find @artifacts.rb@ in the @shared@
directory.
One last thing. You can also treat artifact specifications as hashes. For
Modified: incubator/buildr/trunk/doc/pages/building.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/building.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/building.textile (original)
+++ incubator/buildr/trunk/doc/pages/building.textile Mon Feb 18 15:23:10 2008
@@ -128,7 +128,7 @@
to easily configure it. Methods like @dependencies@ and @sources@ give you a
live array you can manipulate, or iterate over. On the other hand, methods
like @with@ and @from@ accept a wider set of arguments and clean them up for
-you. The also all return the same task you're calling, so you can chain
+you. They also all return the same task you're calling, so you can chain
methods together.
For example:
Modified: incubator/buildr/trunk/doc/pages/contributing.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/contributing.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/contributing.textile (original)
+++ incubator/buildr/trunk/doc/pages/contributing.textile Mon Feb 18 15:23:10
2008
@@ -20,7 +20,7 @@
"buildr-dev":mailto:[EMAIL PROTECTED] mailing list
("subscribe":mailto:[EMAIL PROTECTED],
"archive":http://mail-archives.apache.org/mod_mbox/incubator-buildr-dev/) for
-developement of Buildr itself. We also have a
+development of Buildr itself. We also have a
"commits":mailto:[email protected] mailing list
("subscribe":mailto:[EMAIL PROTECTED]) if you want to
stalk us.
@@ -111,7 +111,7 @@
We always @rake spec@ before making a release.
You can also check out the "RSpec report":report.html and "test coverage
-report":coverage/index.html for the current version of Buildr. And if you
want to help us on the journey to 100% test coverage, we'll be ever so greatful!
+report":coverage/index.html for the current version of Buildr. And if you
want to help us on the journey to 100% test coverage, we'll be ever so grateful!
h2. Documentation
Modified: incubator/buildr/trunk/doc/pages/extending.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/extending.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/extending.textile (original)
+++ incubator/buildr/trunk/doc/pages/extending.textile Mon Feb 18 15:23:10 2008
@@ -17,7 +17,7 @@
{{{!ruby
file('derby.sql') do
- requires = [
+ REQUIRES = [
'org.apache.openjpa:openjpa-all:jar:0.9.7-incubating',
'commons-collections:commons-collections:jar:3.1',
. . .
@@ -26,12 +26,11 @@
ant.taskdef :name=>'mapping',
:classname=>'org.apache.openjpa.jdbc.ant.MappingToolTask',
:classpath=>REQUIRES.join(File::PATH_SEPARATOR)
- ant.mapping :schemaAction=>'build', :sqlFile=>task.name,
- :ignoreErrors=>true do
+ ant.mapping :schemaAction=>'build', :sqlFile=>task.name,
+ :ignoreErrors=>true do
ant.config :propertiesFile=>_(:source, :main, :sql, 'derby.xml')
ant.classpath :path=>projects('store', 'utils' ).
flatten.map(&:to_s).join(File::PATH_SEPARATOR)
- end
end
end
end
Modified: incubator/buildr/trunk/doc/pages/more_stuff.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/more_stuff.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/more_stuff.textile (original)
+++ incubator/buildr/trunk/doc/pages/more_stuff.textile Mon Feb 18 15:23:10 2008
@@ -140,7 +140,7 @@
You can use Ruby to perform ad hoc tasks. For example, Buildr doesn't have
any pre-canned task for setting file permissions. But Ruby has a method for
-just, so it's just a matter of writing a task:
+that, so it's just a matter of writing a task:
{{{!ruby
bins = file('target/bin'=>FileList[_('src/main/dist/bin/*')]) do |task|
Modified: incubator/buildr/trunk/doc/pages/packaging.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/packaging.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/packaging.textile (original)
+++ incubator/buildr/trunk/doc/pages/packaging.textile Mon Feb 18 15:23:10 2008
@@ -8,7 +8,7 @@
}}}
We just told the project to create a JAR file in the @target@ directory,
-including all the classes (and resources) that we previously complied into
+including all the classes (and resources) that we previously compiled into
@target/[EMAIL PROTECTED] Or we can create a WAR file:
{{{!ruby
@@ -159,7 +159,7 @@
include asterisk (@*@) to match any file name or part of a file name, double
asterisk (@**@) to match directories recursively, question mark (@?@) to match
any character, square braces (@[]@) to match a set of characters, and curly
-braces (@{}@) to one of several names.
+braces (@{}@) to match one of several names.
And the same way you @include@, you can also @exclude@ specific files you don't
want showing up in the ZIP. For example, to exclude @.draft@ and @.raw@ files:
@@ -176,7 +176,7 @@
package(:zip).include 'target/docs', :path=>"#{id}-#{version}"
}}}
-If you need to use the @:path@ option repeatedly, consider using the @path@
+If you need to use the @:path@ option repeatedly, consider using the @tap@
method instead. For example:
{{{!ruby
@@ -218,7 +218,7 @@
the directory itself, but strips the path during inclusion. You can define it
now, create these files later, and then ZIP them all up.
-For example, when @package :jar@ decides to include all the files form
+For example, when @package :jar@ decides to include all the files from
@target/classes@, it's still working on the project definition, and has yet to
compile anything. Since @target/classes@ may be empty, may not even exist, it
uses @:as=>'.'@.
@@ -256,9 +256,9 @@
The @services_xml@ attribute points to an Axis2 services configuration file
called @services.xml@ that will be placed in the @META-INF@ directory inside
-the archive. the default behavior is to point to the @services.xml@ file in
+the archive. The default behavior is to point to the @services.xml@ file in
the project's @src/main/axis2@ directory. In the second example above we set
-it explicitly,
+it explicitly.
The @wsdls@ attribute is a collection of file names or glob patterns for WSDL
files that get included in the @META-INF@ directory. In the second example we
@@ -305,7 +305,7 @@
Adding a WAR package assumes it's a WAR component and treats it as such, but
JAR packages can be any of three component types, so by default they are all
treated as shared libraries. If you want to add an EJB or Application Client
-component, you need to say so explicitly, either passing @type=>package@, or by
+component, you need to say so explicitly, either passing @:type=>package@, or
by
passing the component type in the @:type@ option.
Here are three examples:
@@ -336,7 +336,7 @@
}}}
EAR packages include an @application.xml@ file in the @META-INF@ directory that
-describes the application and its component. This file is created for you
+describes the application and its components. This file is created for you
during packaging, by referencing all the components added to the EAR. There
are a couple of things you will typically want to change.
@@ -371,9 +371,7 @@
}}}
The first line creates a Tar archive with the extension @.tar@, the second
-creates a GZipped Tar archive with the extension @[EMAIL PROTECTED] The first
creates a
-Tar archive with the extension @.tar@, the second creates a GZipped Tar archive
-with the extension @[EMAIL PROTECTED]
+creates a GZipped Tar archive with the extension @[EMAIL PROTECTED]
In addition to packaging that includes the archive in the list of
installed/released files, you can use the method @tar@ to create a @[EMAIL
PROTECTED]
Modified: incubator/buildr/trunk/doc/pages/projects.textile
URL:
http://svn.apache.org/viewvc/incubator/buildr/trunk/doc/pages/projects.textile?rev=628918&r1=628917&r2=628918&view=diff
==============================================================================
--- incubator/buildr/trunk/doc/pages/projects.textile (original)
+++ incubator/buildr/trunk/doc/pages/projects.textile Mon Feb 18 15:23:10 2008
@@ -10,7 +10,7 @@
project, like the classpath dependencies, whether you're packaging a JAR or a
WAR, etc.
-The reminder of this guide deals with what it takes to build a project. But
+The remainder of this guide deals with what it takes to build a project. But
first, let's pick up a sample project to work with. We'll call it
_killer-app_:
@@ -95,7 +95,7 @@
using mostly Java, but you can imagine how this pattern applies to other
languages.
-When projects grow big, you split them own into smaller projects by nesting
+When projects grow big, you split them into smaller projects by nesting
projects inside each other. Each sub-project has a sub-directory under the
parent project and follows the same internal directory structure. You can, of
course, change all of that to suite your needs, but if you follow these
@@ -143,8 +143,8 @@
Buildr runs.
When you run the @buildr@ command, it picks up the @buildfile@ (which here
-we'll just call _Buildfile_) from the current directory, or it not there, from
-the closest parent directory. So you can run @buildr@ form any directory
+we'll just call _Buildfile_) from the current directory, or if not there, from
+the closest parent directory. So you can run @buildr@ from any directory
inside your project, and it will always pick up the same Buildfile. That also
happens to be the base directory for the top project. If you have any
sub-projects, Buildr assumes they reflect sub-directories under their parent.
@@ -181,7 +181,10 @@
the project itself. It's syntactic sugar that's useful when accessing project
properties.
-The @projects@ method takes a list of names and returns a list of projects.
If you call it with no arguments on a project, it returns all its sub-projects.
If you call it with no argument in any other context, it returns all the
projects defined so far.
+The @projects@ method takes a list of names and returns a list of projects. If
+you call it with no arguments on a project, it returns all its sub-projects.
+If you call it with no argument in any other context, it returns all the
+projects defined so far.
Let's illustrate this with a few examples:
