Index: src/samples/userguide/tasks/configureUsingClosure/build.gradle
===================================================================
--- src/samples/userguide/tasks/configureUsingClosure/build.gradle	(revision 1562)
+++ src/samples/userguide/tasks/configureUsingClosure/build.gradle	(working copy)
@@ -1,8 +1,8 @@
 // START SNIPPET declare-task
-task copy(type: Copy)
+task myCopy(type: Copy)
 // END SNIPPET declare-task
 
-copy {
+myCopy {
    from(file('resources'))
    into(file('target'))
    includes('**/*.txt', '**/*.xml', '**/*.properties')
Index: src/samples/userguide/tasks/configureUsingConfigure/build.gradle
===================================================================
--- src/samples/userguide/tasks/configureUsingConfigure/build.gradle	(revision 1562)
+++ src/samples/userguide/tasks/configureUsingConfigure/build.gradle	(working copy)
@@ -1,6 +1,6 @@
-task copy(type: Copy)
+task myCopy(type: Copy)
 
-copy.configure {
+myCopy.configure {
    from(file('source'))
    into(file('target'))
    includes('**/*.txt', '**/*.xml', '**/*.properties')
Index: src/samples/userguide/tasks/configureUsingVar/build.gradle
===================================================================
--- src/samples/userguide/tasks/configureUsingVar/build.gradle	(revision 1562)
+++ src/samples/userguide/tasks/configureUsingVar/build.gradle	(working copy)
@@ -1,4 +1,4 @@
-Copy copy = task(copy, type: Copy)
-copy.from(file('resources'))
-copy.into(file('target'))
-copy.includes('**/*.txt', '**/*.xml', '**/*.properties')
+Copy myCopy = task(myCopy, type: Copy)
+myCopy.from(file('resources'))
+myCopy.into(file('target'))
+myCopy.includes('**/*.txt', '**/*.xml', '**/*.properties')
Index: src/samples/userguide/tasks/configureUsingLiterateStyle/build.gradle
===================================================================
--- src/samples/userguide/tasks/configureUsingLiterateStyle/build.gradle	(revision 1562)
+++ src/samples/userguide/tasks/configureUsingLiterateStyle/build.gradle	(working copy)
@@ -1,4 +1,4 @@
-task(copy, type: Copy)
+task(myCopy, type: Copy)
     .from(file('resources'))
     .into(file('target'))
     .includes('**/*.txt', '**/*.xml', '**/*.properties')
Index: src/docs/userguide/plugins.xml
===================================================================
--- src/docs/userguide/plugins.xml	(revision 1562)
+++ src/docs/userguide/plugins.xml	(working copy)
@@ -3,9 +3,9 @@
     <para>Now we look at
         <emphasis>how</emphasis>
         Gradle provides build-by-convention and out of the box functionality. These features are decoupled from the core
-        of Gradle. Gradle provides them via plugins. To make this clear at the very beginning. The plugins provided by
+        of Gradle, and are provided via plugins. To make this clear at the very beginning, the plugins provided by
         Gradle belong to the core distribution of Gradle and they are NEVER updated or changed in any way for a
-        particular Gradle distribution. If there is a bug in the compile functionality of Gradle, we gonna release a new
+        particular Gradle distribution. If there is a bug in the compile functionality of Gradle, we will release a new
         version of Gradle. There is no change of behavior for the lifetime of a given distribution of Gradle. We mention
         this as there is another build tool with a plugin system which behaves differently.
     </para>
@@ -73,8 +73,8 @@
     <section id='sub:more_about_convention_objects'>
         <title>Configuration</title>
         <para>If you use the <emphasis>Java Plugin</emphasis>
-            there is for example a compile and processResources task for your production code (the same is true for your test
-            code). The default location for the output of those task is the directory <literal>build/classes</literal>.
+            for example, there are a compile and a processResources task for your production code (the same is true for your test
+            code). The default location for the output of those tasks is the directory <literal>build/classes</literal>.
             What if you want to change this? Let's try:
         </para>
         <sample id="pluginConfig" dir="userguide/tutorial/pluginConfig">
Index: src/docs/userguide/tasks.xml
===================================================================
--- src/docs/userguide/tasks.xml	(revision 1562)
+++ src/docs/userguide/tasks.xml	(working copy)
@@ -62,20 +62,15 @@
         <sample id="declareTask" dir="userguide/tasks/configureUsingClosure">
             <sourcefile file="build.gradle" snippet="declare-task"/>
         </sample>
-        <para>The copy task provides an API to configure it (see <apilink class="org.gradle.api.tasks.Copy"/>).
-            If you create the copy task like this, it has no default behavior.
-            <footnote>
-                <para>This is different when added by the Java Plugin where it is used for resource processing.
-                </para>
-            </footnote>
-            We want now use the copy task to learn about different ways to configure tasks. The examples below all
-            show different ways to achieve the same configuration.
+        <para>This creates a copy task with no default behavior.
+            The task can be configured using its API (see <apilink class="org.gradle.api.tasks.Copy"/>).
+			The following examples show several different ways to achieve the same configuration.
         </para>
         <sample id="configureUsingVar" dir="userguide/tasks/configureUsingVar">
             <sourcefile file="build.gradle"/>
         </sample>
         <para>This is similar to the way we would normally configure objects in Java. You have to repeat the context
-            (<literal>copy</literal>) in the configuration statement every time. This is a redundancy and not very
+            (<literal>myCopy</literal>) in the configuration statement every time. This is a redundancy and not very
             nice to read.
         </para>
         <para>There is a more convenient way of doing this.
Index: src/docs/userguide/logging.xml
===================================================================
--- src/docs/userguide/logging.xml	(revision 1562)
+++ src/docs/userguide/logging.xml	(working copy)
@@ -86,8 +86,8 @@
     </section>
     <section id='sec:external_tools'>
         <title>External Tools and Standard Output</title>
-        <para>Gradle uses internally Ant and Ivy a lot. Both have their own logging system. Gradle injects an adapter
-            into there logging system to redirect there logging output into the Gradle logging system. There is a 1:1
+        <para>Internally, Gradle uses Ant and Ivy. Both have their own logging system. Gradle injects an adapter
+            into the Ant and Ivy logging systems to redirect their logging output into the Gradle logging system. There is a 1:1
             mapping from the Ant/Ivy log levels to the Gradle log levels, except the Ant/Ivy <emphasis>TRACE</emphasis> level, which is
             mapped to Gradle <emphasis>DEBUG</emphasis>. This means the default Gradle log level does not show any Ant/Ivy output unless it
             is an error or a warning.
Index: src/docs/userguide/artifactMngmt.xml
===================================================================
--- src/docs/userguide/artifactMngmt.xml	(revision 1562)
+++ src/docs/userguide/artifactMngmt.xml	(working copy)
@@ -21,7 +21,7 @@
             them (e.g. upload them). We define the artifacts of the projects as the files the project want to
             provide to the outside world. This can be a library or a distribution or any other file. Usually artifacts
             are archives, but not necessarily. In the Maven world a project can provide only one artifact. With Gradle
-            a project can provide as many artifacts as its like.
+            a project can provide as many artifacts as needed.
         </para>
     </section>
     <section id="artifacts_and_configurations">
@@ -94,12 +94,12 @@
                 100 percent Maven compatible as we use the native Maven Ant tasks under the hood.
             </para>
             <para>Deploying to a Maven repository is only half the fun if you don't have a pom. Fortunately Gradle can
-                generate this pom for your out of the dependency information it has.
+                generate this pom for you using the dependency information it has.
             </para>
         </section>
         <section id='sec:deploying_to_a_maven_repository'>
             <title>Deploying to a Maven Repository</title>
-            <para>Let's assume your projects produces just the default jar file. Now you want to deploy this jar file to
+            <para>Let's assume your project produces just the default jar file. Now you want to deploy this jar file to
                 a remote Maven repository.
             </para>
             <sample id="uploadFile" dir="userguide/artifacts/maven">
@@ -255,8 +255,8 @@
             </para>
             <section id='sub:changing_non_dependency_elements_of_the_pom'>
                 <title>Changing non-dependency elements of the pom</title>
-                <para>You might want that the artifact deployed to the maven repository has a different version or name than
-                    the artifact generated by Gradle. To customize you can do:
+                <para>You might want the artifact deployed to the maven repository to have a different version or name than
+                    the artifact generated by Gradle. To customize these you can do:
                 </para>
                 <sample id="customizePom" dir="userguide/artifacts/maven">
                     <sourcefile file="build.gradle" snippet="customize-pom"/>
Index: src/docs/userguide/buildscripts.xml
===================================================================
--- src/docs/userguide/buildscripts.xml	(revision 1562)
+++ src/docs/userguide/buildscripts.xml	(working copy)
@@ -35,7 +35,7 @@
             closure containing some Groovy code to execute.
         </para>
         <para>If you think this looks similar to Ant's targets, well, you are right. Gradle tasks are the equivalent to
-            Ant targets. But as you will see, they are much more powerful. We have used a different terminology to Ant
+            Ant targets. But as you will see, they are much more powerful. We have used a different terminology than Ant
             as we think the word <emphasis>task</emphasis> is more expressive than the word <emphasis>target</emphasis>.
             Unfortunately this introduces a terminology clash with Ant, as Ant calls its commands, such as
             <literal>javac</literal> or <literal>copy</literal>, tasks. So when we talk about tasks,
@@ -78,7 +78,7 @@
     </section>
     <section>
         <title>Dynamic tasks</title>
-        <para>The power of Groovy be used for more than defining what a task does. For example, you can also use it
+        <para>The power of Groovy can be used for more than defining what a task does. For example, you can also use it
             to dynamically create tasks.
         </para>
         <sample id="dynamic" dir="userguide/tutorial/dynamic">
@@ -157,19 +157,19 @@
         </para>
         <itemizedlist>
             <listitem>
-                <para>Ant task names corresponds to AntBuilder method names.
+                <para>Ant task names correspond to AntBuilder method names.
                 </para>
             </listitem>
             <listitem>
-                <para>Ant tasks attributes are arguments for this methods. The arguments are passed in from of a map.
+                <para>Ant task attributes correspond to arguments to these methods. The arguments are passed to the method using a map.
                 </para>
             </listitem>
             <listitem>
-                <para>Nested Ant tasks corresponds to method calls of the passed closure.
+                <para>Nested Ant tasks correspond to method calls of the passed closure.
                 </para>
             </listitem>
         </itemizedlist>
-        <para>To learn more about the Ant Builder have a look in 'Groovy in Action' 8.4 or at the Groovy Wiki
+        <para>More information about Ant Builder can be found in 'Groovy in Action' 8.4 or at the Groovy Wiki
         </para>
     </section>
     <section>
Index: src/docs/userguide/multiproject.xml
===================================================================
--- src/docs/userguide/multiproject.xml	(revision 1562)
+++ src/docs/userguide/multiproject.xml	(working copy)
@@ -1,7 +1,7 @@
 <chapter id='multi_project_builds' xmlns:xi="http://www.w3.org/2001/XInclude">
     <title>Multi-project Builds</title>
     <para>The powerful support for multi-project builds is one of Gradle's unique selling points. This topic is also the
-        intellectually most challenging.
+        most intellectually challenging.
     </para>
     <section id='sec:cross_project_configuration'>
         <title>Cross Project Configuration</title>
@@ -343,7 +343,7 @@
                     <sourcefile file="producer/build.gradle"/>
                     <output args="-q consume"/>
                 </sample>
-                <para>Uhps. Why does this not work? The
+                <para>Oops. Why does this not work? The
                     <literal>dependsOn</literal>
                     command is created for projects with a common lifecycle. Provided you have two Java projects were
                     one depends on the other. If you trigger a compile for for the dependent project you don't want that
Index: src/docs/userguide/javaPlugin.xml
===================================================================
--- src/docs/userguide/javaPlugin.xml	(revision 1562)
+++ src/docs/userguide/javaPlugin.xml	(working copy)
@@ -766,7 +766,7 @@
 
     <section id='sec:archive_tasks'>
         <title>Archive Tasks</title>
-        <para>An archive task is a task which produces an archive at execution time. The following archives tasks are
+        <para>An archive task is a task which produces an archive at execution time. The following archive tasks are
             available:
         </para>
         <table>
@@ -954,7 +954,7 @@
             <para>The convention object of the Java Plugin has a <literal>manifest</literal>
                 property pointing to an instance of <apilink class="org.gradle.api.tasks.bundling.GradleManifest" lang="groovy"/>.
                 With this <classname>GradleManifest</classname> object you can define the content of the
-                <filename>MANIFEST.MF</filename> file of all the jar or a war archives in your project.
+                <filename>MANIFEST.MF</filename> file for all the jar or a war archives in your project.
             </para>
             <sample id="manifest" dir="userguide/tutorial/manifest">
                 <sourcefile file="build.gradle" snippet="main-attributes"/>
@@ -974,7 +974,7 @@
         <section id='sub:metainf'>
             <title>MetaInf</title>
             <para>The convention object of the Java Plugin has a <literal>metaInf</literal> property pointing to a list of
-                <classname>FileSet</classname> objects. With this file sets you can define which files should be in the
+                <classname>FileSet</classname> objects. With these file sets you can define which files should be in the
                 <filename>META-INF</filename> directory of a JAR or a WAR archive.
             </para>
             <programlisting><![CDATA[
Index: src/docs/userguide/overview.xml
===================================================================
--- src/docs/userguide/overview.xml	(revision 1562)
+++ src/docs/userguide/overview.xml	(working copy)
@@ -102,8 +102,8 @@
                 <term>Partial Builds</term>
                 <listitem>
                     <para>With Maven multi-project builds only work if executed from the root project and thus requiring
-                        a complete build. If you build from a subproject, only the subproject is build, not the projects
-                        the subproject depends on. Gradle offers partial builds. The subproject is build plus the
+                        a complete build. If you build from a subproject, only the subproject is built, not the projects
+                        the subproject depends on. Gradle offers partial builds. The subproject is built plus the
                         projects it depends on. This is very convenient for larger builds.
                     </para>
                 </listitem>
Index: src/docs/userguide/warPlugin.xml
===================================================================
--- src/docs/userguide/warPlugin.xml	(revision 1562)
+++ src/docs/userguide/warPlugin.xml	(working copy)
@@ -30,7 +30,7 @@
 
     <section>
         <title>Configurations</title>
-        <para>The War plugin add two dependency configurations: <literal>providedCompile</literal> and
+        <para>The War plugin adds two dependency configurations: <literal>providedCompile</literal> and
             <literal>providedRuntime</literal>. Those configurations have the same scope as the respective
             <literal>compile</literal> and <literal>runtime</literal> configurations, except that they are not added to
             the WAR archive. It is important to note that those <literal>provided</literal> configurations work
@@ -93,7 +93,7 @@
     </section>
     <section id='sec:customizing'>
         <title>Customizing</title>
-        <para>Here an example with the most important customization options:
+        <para>Here is an example with the most important customization options:
         </para>
         <sample id="webproject" dir="webApplication/customised">
             <sourcefile file="build.gradle"/>
Index: src/docs/userguide/thisAndThat.xml
===================================================================
--- src/docs/userguide/thisAndThat.xml	(revision 1562)
+++ src/docs/userguide/thisAndThat.xml	(working copy)
@@ -53,7 +53,7 @@
         </section>
         <section>
         <title>Enabling and disabling tasks</title>
-        <para>Every task has also a <literal>enabled</literal>
+        <para>Every task has also an <literal>enabled</literal>
             flag which defaults to <literal>true</literal>. Setting it to <literal>false</literal> prevents the execution of any of the
             task's actions.
         </para>
@@ -119,7 +119,7 @@
             <output args="-q otherResources"/>
         </sample>
         <para>A <emphasis>Directory Task</emphasis>
-            is a simple task which name is a relative path to the project dir
+            is a simple task whose name is a relative path to the project dir
             <footnote>
                 <para>The notation <literal>dir('/somepath')</literal> is a convenience method for
                     <literal>tasks.add('somepath', type: Directory)</literal>
@@ -183,7 +183,7 @@
         </sample>
         <section id='sub:checking_for_project_properties'>
             <title>Checking for Project Properties</title>
-            <para>You can access a project property in your build script simply by using it name as you would use a
+            <para>You can access a project property in your build script simply by using its name as you would use a
                 variable. In case this property does not exists, an exception is thrown and the build fails. If your
                 build script relies on optional properties the user might set for example in a gradle.properties file,
                 you need to check for existence before you can access them. You can do this by using the method
Index: src/docs/userguide/depMngmt.xml
===================================================================
--- src/docs/userguide/depMngmt.xml	(revision 1562)
+++ src/docs/userguide/depMngmt.xml	(working copy)
@@ -65,17 +65,17 @@
         <section id='sub:transitive_dependency_management'>
             <title>Transitive dependency management</title>
             <para>Why is transitive dependency management so important? If you don't know which dependencies are first
-                level dependencies and which ones are transitive you are loosing very soon control over your build. Even
+                level dependencies and which ones are transitive you will soon lose control over your build. Even
                 Gradle has already 20+ jars. An enterprise project using Spring, Hibernate, etc. easily ends up with
-                100+ jars. There is no way to memorize where all these jars belong to. If you want to get rid of a first
-                level dependency you can't be sure which other jars you should remove. Because a dependency of your
+                100+ jars. There is no way to memorize where all these jars come from. If you want to get rid of a first
+                level dependency you can't be sure which other jars you should remove. Because a dependency of a
                 first level dependency might also be a first level dependency itself. Or it might be a transitive
-                dependency of another of your first level dependency. Many first level dependencies are runtime
+                dependency of another of your first level dependencies. Many first level dependencies are runtime
                 dependencies and the transitive dependencies are of course all runtime dependencies. So the compiler
-                won't help you much here. The end of the story is, as we have seen very often, nobody dares to remove
-                any jar any longer. The project classpath is a complete mess and if a classpath problems arises, hell on
-                earth invites you for a ride. In one of my former projects, I've found some ldap related jar in the
-                classpath, which sheer presence, as I've found out after much research, accelerated LDAP access. So
+                won't help you much here. The end of the story is, as we have seen very often, no one dares to remove
+                any jar any longer. The project classpath is a complete mess and if a classpath problem arises, hell on
+                earth invites you for a ride. In one of my former projects, I found some ldap related jar in the
+                classpath, whose sheer presence, as I found out after much research, accelerated LDAP access. So
                 removing this jar would not have led to any errors at compile or runtime.
             </para>
             <para>Gradle offers you different ways to express what are first level and what are transitive dependencies.
@@ -87,7 +87,7 @@
         <section id='sub:version_conflicts'>
             <title>Version conflicts</title>
             <para>In your dependency description you tell Gradle which version of a dependency is needed by another
-                dependency. This leads frequently to conflicts. Different dependencies rely on different versions of
+                dependency. This frequently leads to conflicts. Different dependencies rely on different versions of
                 another dependency. The JVM unfortunately does not offer yet any easy way, to have different versions of
                 the same jar in the classpath (see <xref linkend='sub:dependency_management_and_java'/>). What Gradle
                 offers you is a resolution strategy, by default the newest version is used. To deal with problems due to
@@ -127,7 +127,7 @@
     </section>
     <section id='sec:how_to_declare_your_dependencies'>
         <title>How to declare your dependencies</title>
-        <para>People who know Ivy have come across most the concepts we are going to introduce now. But Gradle does not
+        <para>People who know Ivy have come across most of the concepts we are going to introduce now. But Gradle does not
             use any XML for declaring the dependencies (e.g. no
             <literal>ivy.xml</literal>
             file). It has its own notations which is part of the Gradle build file.
@@ -239,7 +239,7 @@
             <sample id="project-dependencies" dir="java/multiproject/api">
                 <sourcefile file="build.gradle" snippet="project-dependencies"/>
             </sample>
-            <para>Have also a look at the javadoc: <apilink class="org.gradle.api.artifacts.ProjectDependency"/>
+            <para>For more information see the javadoc: <apilink class="org.gradle.api.artifacts.ProjectDependency"/>
             </para>
             <para>Multi-project builds are discussed in <xref linkend='multi_project_builds'/>.
             </para>
@@ -487,8 +487,8 @@
             <para>Let's say, you declare a dependency on the 
                 <literal>junit:junit:3.8.2</literal> library.
                 Now how does Gradle find it in the repositories? Somehow the dependency information has to be mapped to a
-                path. In contrast to Maven, where this path is fixed, with Gradle you can define a pattern how this path
-                should look like. Here are some examples:
+                path. In contrast to Maven, where this path is fixed, with Gradle you can define a pattern that defines
+                what the path will look like. Here are some examples:
                 <footnote>
                     <para>At
                         <ulink url='http://ant.apache.org/ivy/history/latest-milestone/concept.html'/>
@@ -518,7 +518,7 @@
         </section>
     </section>
     <section id='sec:strategies_of_transitive_dependency_management'>
-        <title>Strategies of transitive dependency management</title>
+        <title>Strategies for transitive dependency management</title>
         <para>Many projects rely on the <ulink url='http://repo1.maven.org/maven2'>Maven2 repository</ulink>. This is not
             without problems.
         </para>
