Index: trunk/src/docs/userguide/projectTaskApi.xml
===================================================================
--- trunk/src/docs/userguide/projectTaskApi.xml	(revision 1213)
+++ trunk/src/docs/userguide/projectTaskApi.xml	(working copy)
@@ -3,7 +3,7 @@
     <section id='sec:project_api'>
         <title>Project API</title>
         <para>In the tutorial in <xref linkend='cha:gradle_core_tutorial'/>
-            we have called for example the method<literal>createTask</literal>. Where does this method come from? We
+            we have called for example the method <literal>createTask</literal>. Where does this method come from? We
             said earlier that the directory containing the build script defines a project for Gradle. For Gradle this
             means, that it creates an instance of
             <literal>org.gradle.api.Project</literal>
@@ -39,7 +39,7 @@
             you define a property or a method which has the same name as a member of the project object, you need to use
             the
             <literal>project</literal>
-            property. Look here to learn more about<ulink
+            property. Look here to learn more about <ulink
                     url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/Project.html'>org.gradle.api.Project</ulink>.
         </para>
     </section>
@@ -75,7 +75,7 @@
             We think that one thing that makes Gradle special compared to the other tools, is its strong support for
             applying dependency based programming on
             <literal>multiproject</literal>
-            builds. We also think that just Gradles core layer (together with its integration of the Ant tasks),
+            builds. We also think that just Gradle's core layer (together with its integration of the Ant tasks),
             provides a more convenient build system than Ant's core layer.
         </para>
     </section>
Index: trunk/src/docs/userguide/ideSupport.xml
===================================================================
--- trunk/src/docs/userguide/ideSupport.xml	(revision 1213)
+++ trunk/src/docs/userguide/ideSupport.xml	(working copy)
@@ -2,7 +2,7 @@
     <title>Existing IDE Support and how to cope without it</title>
     <section id='sec:intellij'>
         <title>IntelliJ</title>
-        <para>Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradles build script
+        <para>Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradle's build script
             <footnote>
                 <para>Gradle is build with Gradle
                 </para>
@@ -10,7 +10,7 @@
             has also been developed with the support of this IDE. IntelliJ allows you to define any filepattern to be
             interpreted as a Groovy script. In the case of Gradle you can define such a pattern for
             <emphasis>build.gradle</emphasis>
-            and<emphasis>settings.gradle</emphasis>. This will already help very much. What is missing is the classpath
+            and <emphasis>settings.gradle</emphasis>. This will already help very much. What is missing is the classpath
             to the Gradle binaries to offer content assistance for the Gradle classes. You might add the gradle jar
             (which you can find in your distribution) to your project's classpath. It does not really belong there, but
             if you do this you have a fantastic IDE support for developing Gradle scripts. Of course if you use
@@ -17,7 +17,7 @@
             additional libraries for your build scripts they would further pollute your project classpath.
         </para>
         <para>We hope that in the future
-            <literal>build.gradles</literal>
+            <literal>build.Gradle's</literal>
             get special treatment by IntelliJ and you will be able to define a specific classpath for them.
         </para>
     </section>
Index: trunk/src/docs/userguide/overview.xml
===================================================================
--- trunk/src/docs/userguide/overview.xml	(revision 1213)
+++ trunk/src/docs/userguide/overview.xml	(working copy)
@@ -137,7 +137,7 @@
     <section id='sec:why_groovy'>
         <title>Why Groovy?</title>
         <para>We think the advantages of an internal DSL (based on a dynamic language) over XML are tremendous in case
-            of<emphasis>build scripts</emphasis>. There are a couple of dynamic languages out there. Why Groovy? The
+            of <emphasis>build scripts</emphasis>. There are a couple of dynamic languages out there. Why Groovy? The
             answer lies in the context Gradle is operating in. Although Gradle is a general purpose build tool at its
             core, its main focus are Java projects.
             <footnote>
Index: trunk/src/docs/userguide/thisAndThat.xml
===================================================================
--- trunk/src/docs/userguide/thisAndThat.xml	(revision 1213)
+++ trunk/src/docs/userguide/thisAndThat.xml	(working copy)
@@ -59,7 +59,7 @@
         </para>
         <para>Every task has also a
             <literal>enabled</literal>
-            flag which defaults to<literal>true</literal>. Setting it to false prevents the execution of any of the
+            flag which defaults to <literal>true</literal>. Setting it to false prevents the execution of any of the
             tasks actions.
         </para>
         <sample src='userguide/tutorial/disableTask/build.gradle'
@@ -157,7 +157,7 @@
             command line option. For more exotic use cases you can even pass properties
             <emphasis>directly</emphasis>
             to the project object via system and environment properties. For example if you run a build on a continuous
-            integration server where you have no admin rights for the<emphasis>machine</emphasis>. Your build script
+            integration server where you have no admin rights for the <emphasis>machine</emphasis>. Your build script
             needs properties which values should not be seen by others. Therefore you can't use the
             <literal>-P</literal>
             option. In this case you can add an environment property in the project adminstration section (invisible to
@@ -170,11 +170,11 @@
                     are for example CI servers which offer this functionality
                 </para>
             </footnote>
-            If the environment property follows the pattern<literal>ORG_GRADLE_PROJECT_yourProperty=somevalue</literal>,
+            If the environment property follows the pattern <literal>ORG_GRADLE_PROJECT_yourProperty=somevalue</literal>,
             <literal>yourProperty</literal>
             is added to your project object. If in the future CI servers support Gradle directly, they might start
             Gradle via its main method. Therefore we already support the same mechanism for system properties. The only
-            difference is the prefix, which is<literal>org.gradle.project.</literal>.
+            difference is the prefix, which is <literal>org.gradle.project.</literal>.
         </para>
         <para>With the
             <literal>gradle.properties</literal>
@@ -196,7 +196,7 @@
                 <literal>hasProperty('propertyName')</literal>
                 which returns
                 <literal>true</literal>
-                or<literal>false</literal>.
+                or <literal>false</literal>.
             </para>
         </section>
     </section>
@@ -204,7 +204,7 @@
         <title>Accessing the web via a proxy</title>
         <para>Setting a proxy for web access (for example for downloading dependencies) is easy. Gradle does not need to
             provide special functionality for this. The JVM can be instructed to go via proxy by setting certain system
-            properties. You could set this system properties directly in your build script with<literal>
+            properties. You could set this system properties directly in your build script with <literal>
                 System.properties['proxy.proxyUser'] = 'userid'</literal>. An arguably nicer way is shown in
             <xref linkend='sec:gradle_properties_and_system_properties'/>. Your gradle.properties file could look like
             this:
@@ -238,7 +238,7 @@
             <literal>-r</literal>
             option, the build script is always compiled and stored in the cache. That way you can always rebuild the
             cache if for example the timestamps for some reasons don't reflect that the build script needs to be
-            recomiled.
+            recompiled.
         </para>
     </section>
     <section id='sec:configuring_arbitrary_objects'>
Index: trunk/src/docs/userguide/plugins.tex
===================================================================
--- trunk/src/docs/userguide/plugins.tex	(revision 1213)
+++ trunk/src/docs/userguide/plugins.tex	(working copy)
@@ -20,7 +20,7 @@
 \outputInputTutorial{pluginIntro}
 The JavaPlugin adds a \texttt{compile} task to the project object which can be accessed by a build script.
 
-\noindent The usePlugin method either takes a string or a class as an argument. You can write\footnote{Thanks to Gradles default imports (see \ref{cha:ide_support}) you can also write \texttt{usePlugin(JavaPlugin)} in this case.}
+\noindent The usePlugin method either takes a string or a class as an argument. You can write\footnote{Thanks to Gradle's default imports (see \ref{cha:ide_support}) you can also write \texttt{usePlugin(JavaPlugin)} in this case.}
 \begin{Verbatim}
 usePlugin(org.gradle.api.plugins.JavaPlugin)
 \end{Verbatim} 
@@ -35,7 +35,7 @@
 \outputInputTutorial{pluginConfig}
 Setting the \texttt{destinationDir} of the resources task had only an effect on the resources task. Maybe this was what you wanted. But what if you want to change the output directory for all tasks? It would be unfortunate if you had to do this for each task separately. 
 
-Gradles tasks are usually \emph{convention aware}. A plugin can add a convention object to your build. It can also map certain values of this convention object to task properties.
+Gradle's tasks are usually \emph{convention aware}. A plugin can add a convention object to your build. It can also map certain values of this convention object to task properties.
 \codeInput{../../samples/userguide/tutorial/pluginConvention/build.gradle}
 \outputInputTutorial{pluginConvention}
 The \emph{JavaPlugin} has added a convention object with a \texttt{classesDirName} property. The properties of a convention object can be accessed like project properties. As shown in the example, you can also access the convention object explicitly.
Index: trunk/src/docs/userguide/thisAndThat.tex
===================================================================
--- trunk/src/docs/userguide/thisAndThat.tex	(revision 1213)
+++ trunk/src/docs/userguide/thisAndThat.tex	(working copy)
@@ -91,7 +91,7 @@
 
 \section{Caching} % (fold)
 \label{sec:caching}
-To improve the responsiveness Gradle caches the compiled build script by default. The first time you run a build for a project, Gradle creates a \texttt{.gradle} directory in which it puts the compiled build script. The next time you run this build, Gradle uses the compiled build script, if the timestamp of the compiled script is newer than the timestamp of the actual build script. Otherwise the build script gets compiled and the new version is stored in the cache. If you run Gradle with the \texttt{-x} option, any existing cache is ignored and the build script is compiled and executed on the fly. If you run Gradle with the \texttt{-r} option, the build script is always compiled and stored in the cache. That way you can always rebuild the cache if for example the timestamps for some reasons don't reflect that the build script needs to be recomiled. 
+To improve the responsiveness Gradle caches the compiled build script by default. The first time you run a build for a project, Gradle creates a \texttt{.gradle} directory in which it puts the compiled build script. The next time you run this build, Gradle uses the compiled build script, if the timestamp of the compiled script is newer than the timestamp of the actual build script. Otherwise the build script gets compiled and the new version is stored in the cache. If you run Gradle with the \texttt{-x} option, any existing cache is ignored and the build script is compiled and executed on the fly. If you run Gradle with the \texttt{-r} option, the build script is always compiled and stored in the cache. That way you can always rebuild the cache if for example the timestamps for some reasons don't reflect that the build script needs to be recompiled. 
 % section caching (end)
 
 \section{Configuring Arbitrary Objects} % (fold)
Index: trunk/src/docs/userguide/plugins.xml
===================================================================
--- trunk/src/docs/userguide/plugins.xml	(revision 1213)
+++ trunk/src/docs/userguide/plugins.xml	(working copy)
@@ -47,7 +47,7 @@
         </para>
         <para>The usePlugin method either takes a string or a class as an argument. You can write
             <footnote>
-                <para>Thanks to Gradles default imports (see <xref linkend='cha:ide_support'/>) you can also write
+                <para>Thanks to Gradle's default imports (see <xref linkend='cha:ide_support'/>) you can also write
                     <literal>usePlugin(JavaPlugin)</literal>
                     in this case.
                 </para>
@@ -75,7 +75,7 @@
         <para>If you use the
             <emphasis>JavaPlugin</emphasis>
             there is for example a compile and resources 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>.
+            code). The default location for the output of those task is the directory <literal>build/classes</literal>.
             What if you want to change this? Let's try:
         </para>
         <sample src='userguide/tutorial/pluginConfig/build.gradle'
@@ -87,7 +87,7 @@
             you want to change the output directory for all tasks? It would be unfortunate if you had to do this for
             each task separately.
         </para>
-        <para>Gradles tasks are usually<emphasis>convention aware</emphasis>. A plugin can add a convention object to
+        <para>Gradle's tasks are usually <emphasis>convention aware</emphasis>. A plugin can add a convention object to
             your build. It can also map certain values of this convention object to task properties.
         </para>
         <sample src='userguide/tutorial/pluginConvention/build.gradle'
Index: trunk/src/docs/userguide/groovyPlugin.xml
===================================================================
--- trunk/src/docs/userguide/groovyPlugin.xml	(revision 1213)
+++ trunk/src/docs/userguide/groovyPlugin.xml	(working copy)
@@ -4,7 +4,7 @@
         <footnote>
             <para>We don't recommend this, as the Groovy plugin uses the
                 <emphasis>Groovyc</emphasis>
-                Ant task to compile the sources. For pure Java projects you might rather stick with pure<literal>
+                Ant task to compile the sources. For pure Java projects you might rather stick with pure <literal>
                     javac</literal>. In particular as you would have to supply a groovy jar for doing this.
             </para>
         </footnote>
@@ -12,7 +12,7 @@
         It modifies some of the tasks of the JavaPlugin and adds to the
         <emphasis>Convention</emphasis>
         object. See <xref linkend='groovylayout'/>, <xref linkend='groovyconvention'/>
-        and <xref linkend='groovyconventionFloatingDir'/>. It also add a new dependency configuration<literal>
+        and <xref linkend='groovyconventionFloatingDir'/>. It also add a new dependency configuration <literal>
             groovy</literal>.
     </para>
     <para>Gradle is written in Groovy and offers you to write your build scripts in Groovy. But this is an internal
@@ -148,7 +148,7 @@
             <emphasis>GroovyCompile</emphasis>
             task has two instances,
             <literal>compile</literal>
-            and<literal>testCompile</literal>. The task type extends the
+            and <literal>testCompile</literal>. The task type extends the
             <literal>Compile</literal>
             task (see <xref linkend='sec:compile'/>)
         </para>
Index: trunk/src/docs/userguide/overview.tex
===================================================================
--- trunk/src/docs/userguide/overview.tex	(revision 1213)
+++ trunk/src/docs/userguide/overview.tex	(working copy)
@@ -47,7 +47,7 @@
 % 
 % \begin{description}
 % \item[Maximum Freedom] We think the build-by-convention approach is very suitable for builds. This approach is supported by Gradle. Amongst other things, it makes a build faster to create and easier to maintain. Yet builds are often complex beasts and not every aspect of a build fits into a framework. We think  a build system that is good for 80\% of your build requirements but is an obstacle you have to fight with for the remaining 20\% is not worth using. Solving the remaining 20 percent is very expensive, and as it usually involves tweaking, makes the build very hard to maintain and to comprehend. Even worse, you don't implement desired functionality because it is too hard or impossible to do. A build is too important for your project to accept such constraints.
-% Gradle solves this problem. Gradle is not a build framework, it provides build frameworks on top of its other layers. You can even develop custom build frameworks with Gradle. If those frameworks do not provide what you want, there are many ways to configure them. You can easily switch of existing functionality or replace single bits of the framework with custom functionality. If your requirements don't fit into the framework at all, you just don't use the build-by-convention framework. You might use Gradle build-in tasks and assemble them in your own way. Or you just use the core of Gradle, where you have utmost flexibility. For example you have a multi-project build with ten projects and for nine Gradles build-by-convention framework is suitable but one project does not fit in. No problem. You enable the framework only for the projects where you need them. We never lock you in! We promise!
+% Gradle solves this problem. Gradle is not a build framework, it provides build frameworks on top of its other layers. You can even develop custom build frameworks with Gradle. If those frameworks do not provide what you want, there are many ways to configure them. You can easily switch of existing functionality or replace single bits of the framework with custom functionality. If your requirements don't fit into the framework at all, you just don't use the build-by-convention framework. You might use Gradle build-in tasks and assemble them in your own way. Or you just use the core of Gradle, where you have utmost flexibility. For example you have a multi-project build with ten projects and for nine Gradle's build-by-convention framework is suitable but one project does not fit in. No problem. You enable the framework only for the projects where you need them. We never lock you in! We promise!
 % \item[Powerful] Gradle's build scripts are written in Groovy not XML. You have the full power of a mighty OO-language at your fingertips. Gradle requires no unnecessary indirections for integrating your functionality. The build language offers very flexible configuration options. Our dependency management is based on Ivy, the by far most advanced and powerful dependency management system in the Java world. Gradle offers utmost flexiblity when it comes to multi project builds, by providing configuration injection and separate configuration and execution dependency graphs. Gradle is as simple as possible but when it comes to heavy lifting you have a very strong partner.
 % \item[Scalable] There are many ways a build system can and should scale. Easy things should be straight forward to implement. For complex things you need a different, appropriate support. For example:
 % 
Index: trunk/src/docs/userguide/osgi.xml
===================================================================
--- trunk/src/docs/userguide/osgi.xml	(revision 1213)
+++ trunk/src/docs/userguide/osgi.xml	(working copy)
@@ -3,7 +3,7 @@
     <para>The Gradle OSGi plugin enables the generation of an OSGi manifest. This OSGi manifest is automatically added
         to the jars produces by the Java plugin
         <literal>libs</literal>
-        bundle. This plugin makes heavy use of Peter Kriens<ulink url='http://www.aqute.biz/Code/Bnd'>BND tool</ulink>.
+        bundle. This plugin makes heavy use of Peter Kriens <ulink url='http://www.aqute.biz/Code/Bnd'>BND tool</ulink>.
     </para>
     <para>The OSGi plugin adds an
         <literal>osgi</literal>
@@ -13,7 +13,7 @@
         <literal>libs</literal>
         bundle. This
         <literal>osgi</literal>
-        property points to an instance of<ulink
+        property points to an instance of <ulink
                 url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/plugins.osgi/OsgiManifest.html'>
             org.gradle.api.plugins.osgi.OsgiManifest</ulink>. Via the OsgiManifest object you can control the generation
         of the OSGi Manifest of the respective jar. The OSGi plugin assign default values to the OsgiManifest object.
@@ -74,7 +74,7 @@
     <para>The first argument of the instruction call is the key of the property. The other arguments form the value.
         They are joined by Gradle with the
         <literal>,</literal>
-        separator. To learn more about the available instructions have a look at the<ulink
+        separator. To learn more about the available instructions have a look at the <ulink
                 url='http://www.aqute.biz/Code/Bnd'>BND tool</ulink>.
     </para>
 </chapter>
Index: trunk/src/docs/userguide/projectTaskApi.tex
===================================================================
--- trunk/src/docs/userguide/projectTaskApi.tex	(revision 1213)
+++ trunk/src/docs/userguide/projectTaskApi.tex	(working copy)
@@ -19,7 +19,7 @@
 Many of the methods of the project object return task objects. We have already seen some ways on how to use the task objects in chapter \ref{cha:gradle_core_tutorial}. Look here to learn more about \href{\API Task.html}{org.gradle.api.Task}.
 % section task_api (end)
 \section{Summary} % (fold)
-The project and the task API constitute the core layer of Gradle and provide all the possible interaction options with this layer.\footnote{There is more to come for this layer in the other chapters, e.g. support for multi-project builds (see chapter \ref{cha:multi_project_builds}).} This core-layer constitutes a language for dependency based programming.\footnote{Martin Fowler has written about this: \url{http://martinfowler.com/articles/rake.html\#DependencyBasedProgramming}} There are many other projects providing such a language. There is Ant for Java, Rake and Rant for Ruby, SCons for Python, the good old Make and many more.\footnote{Interestingly, Maven2 is the only major build system which does not use dependency based programming.} We think that one thing that makes Gradle special compared to the other tools, is its strong support for applying dependency based programming on \texttt{multiproject} builds. We also think that just Gradles core layer (together with its integration of the Ant tasks), provides a more convenient build system than Ant's core layer.
+The project and the task API constitute the core layer of Gradle and provide all the possible interaction options with this layer.\footnote{There is more to come for this layer in the other chapters, e.g. support for multi-project builds (see chapter \ref{cha:multi_project_builds}).} This core-layer constitutes a language for dependency based programming.\footnote{Martin Fowler has written about this: \url{http://martinfowler.com/articles/rake.html\#DependencyBasedProgramming}} There are many other projects providing such a language. There is Ant for Java, Rake and Rant for Ruby, SCons for Python, the good old Make and many more.\footnote{Interestingly, Maven2 is the only major build system which does not use dependency based programming.} We think that one thing that makes Gradle special compared to the other tools, is its strong support for applying dependency based programming on \texttt{multiproject} builds. We also think that just Gradle's core layer (together with its integration of the Ant tasks), provides a more convenient build system than Ant's core layer.
 % section summary (end)
 
 % chapter the_project_and_task_api (end)
\ No newline at end of file
Index: trunk/src/docs/userguide/javaTutorial.xml
===================================================================
--- trunk/src/docs/userguide/javaTutorial.xml	(revision 1213)
+++ trunk/src/docs/userguide/javaTutorial.xml	(working copy)
@@ -31,7 +31,7 @@
             <literal>shared</literal>
             is code used both by
             <literal>api</literal>
-            and<literal>webservice</literal>. Let's look at the Gradle build scripts of those projects.
+            and <literal>webservice</literal>. Let's look at the Gradle build scripts of those projects.
         </para>
         <programlisting><![CDATA[
 subprojects {
@@ -75,7 +75,7 @@
             <literal>shared</literal>
             project. Due to this dependency
             <literal>shared</literal>
-            gets now always build before<literal>api</literal>. We also add a distribution, that gets shipped to the
+            gets now always build before <literal>api</literal>. We also add a distribution, that gets shipped to the
             client.
         </para>
     </section>
Index: trunk/src/docs/userguide/depMngmt.tex
===================================================================
--- trunk/src/docs/userguide/depMngmt.tex	(revision 1213)
+++ trunk/src/docs/userguide/depMngmt.tex	(working copy)
@@ -201,7 +201,7 @@
 
 \subsection{Enterprise Environments} % (fold)
 \label{sub:enterprise_environments}
-In a larger enterprise environment you are likely to have a number of independent builds, possibly many different, large multi-project builds. Here a repository infrastructure makes a lot of sense. You have already infrastructure that guarantees a high uptime. Multiple projects can share there information about certain common dependencies they have. There is a central place to look for dependency information. And the repositories are used to integrate the internal projects with each other. One project publishes itself to the company repository, with all its dependency information stored in an ivy.xml or pom.xml file.\footnote{As discussed in \ref{sub:other_environments} this will be also possible with client modules in a future release.} Together with a continous integration server this offers a strong integration for projects with separate builds. As you have seen, Gradle fully supports this approach.
+In a larger enterprise environment you are likely to have a number of independent builds, possibly many different, large multi-project builds. Here a repository infrastructure makes a lot of sense. You have already infrastructure that guarantees a high uptime. Multiple projects can share there information about certain common dependencies they have. There is a central place to look for dependency information. And the repositories are used to integrate the internal projects with each other. One project publishes itself to the company repository, with all its dependency information stored in an ivy.xml or pom.xml file.\footnote{As discussed in \ref{sub:other_environments} this will be also possible with client modules in a future release.} Together with a continuous integration server this offers a strong integration for projects with separate builds. As you have seen, Gradle fully supports this approach.
 % subsection enterprise_environments (end)
 
 \subsection{Other environments} % (fold)
@@ -258,7 +258,7 @@
 	addMavenStyleRepo('myrepo', 'http://repo.gradle.org')
 }
 \end{Verbatim}
-Quite often certain jars are not in the official Maven repository for licensing reasons (e.g. JTA). But the poms are there and you want to use them. Gradle (and Ivy) use the same resolver to look for the pom and the corresponding artifact. It is not possible to define a chain of resolvers, where one resolver is used for retrieving the pom and another resolver is used for retrieving the artifact. For the dependencies of the artifact the chain of resolvers can be used. To solve this problem
+Quite often certain jars are not in the official Maven repository for licensing reasons (e.g. JTA). But the poms are there and you want to use them. Gradle (and Ivy) use the same resolver to look for the pom and the corresponding artifact. It is now possible to define a chain of resolvers, where one resolver is used for retrieving the pom and another resolver is used for retrieving the artifact. For the dependencies of the artifact the chain of resolvers can be used. To solve this problem
 \begin{Verbatim}
 dependencies {
 	addMavenRepo('http://repo.gradle.org', 'http://repo2.gradle.org')
@@ -342,7 +342,7 @@
 
 \subsection{Resolver Container} % (fold)
 \label{sub:resolver_container}
-There are three hooks for adding resolvers. Via the resolvers assigned to the \texttt{classpathResolvers} property of the dependency manager, the \texttt{compile}, \texttt{testCompile} and \texttt{test} tasks retrieve there dependencies. The \texttt{uploadLibs} and \texttt{uploadDists} tasks have both an \texttt{uploadResolvers} property. You can assign one resolver to multiple hooks.
+There are three hooks for adding resolvers. Via the resolvers assigned to the \texttt{classpathResolvers} property of the dependency manager, the \texttt{compile}, \texttt{testCompile} and \texttt{test} tasks retrieve their dependencies. The \texttt{uploadLibs} and \texttt{uploadDists} tasks have both an \texttt{uploadResolvers} property. You can assign one resolver to multiple hooks.
 
 All of those hooks are instances of \href{\API dependencies/ResolverContainer.html}{\PKG dependencies.ResolverContainer}. This class provided methods for adding new resolvers at a particular position in the resolve chain.\footnote{Ivy power users can set \texttt{dependencies.chainConfigurer = { // some statements }}. This closure is applied to the \texttt{ChainResolver} containing the other Ivy resolvers.} Ivy offers more complex structures for resolvers than simple chains. The resolver container does not offer particular support for this. But by manipulating its properties directly you could set up such other structures.
 % subsection resolver_container (end)
@@ -354,7 +354,7 @@
 	\item There are many options for the protocol to communicate with the repository (e.g. filesystem, http, ssh, ...)
 	\item Each repository can have its own layout.
 \end{itemize}
-If you declare a dependency like \texttt{junit:junit:3.8.2} how does Gradle finds 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:\footnote{At \url{http://ant.apache.org/ivy/history/latest-milestone/concept.html} you can learn more about ivy patterns.}
+If you declare a dependency like \texttt{junit:junit:3.8.2} 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:\footnote{At \url{http://ant.apache.org/ivy/history/latest-milestone/concept.html} you can learn more about ivy patterns.}
 \begin{Verbatim}
 // Maven2 layout (if a repository is marked as Maven2 compatible, the organization (group) is split into subfolders according to the dots.)
 someroot/[organisation]/[module]/[revision]/[module]-[revision].[ext]
@@ -375,6 +375,6 @@
 	        addArtifactPattern(root + "[artifact]-[revision].[ext]")
 }
 \end{Verbatim}
-\texttt{WebdavResolver} is a class that implements an Ivy interface and is part of the \emph{Gradle} distribution. An overview of which Resolvers are offered by Ivy and thus also by Gradle can be found \href{http://ant.apache.org/ivy/latest-milestone/configuration/resolvers.html}{here}. With Gradle you just don't configure them via xml but directly via there API.
+\texttt{WebdavResolver} is a class that implements an Ivy interface and is part of the \emph{Gradle} distribution. An overview of which Resolvers are offered by Ivy and thus also by Gradle can be found \href{http://ant.apache.org/ivy/latest-milestone/configuration/resolvers.html}{here}. With Gradle you just don't configure them via xml but directly via their API.
 % subsection more_about_ivy_resolvers (end)
 % section repositories (end)
\ No newline at end of file
Index: trunk/src/docs/userguide/depMngmt.xml
===================================================================
--- trunk/src/docs/userguide/depMngmt.xml	(revision 1213)
+++ trunk/src/docs/userguide/depMngmt.xml	(working copy)
@@ -83,7 +83,7 @@
             <para>Traditionally, Java has offered no support at all for dealing with libraries and versions. There are
                 no standard ways to say that
                 <literal>foo-1.0.jar</literal>
-                depends on a<literal>bar-2.0.jar</literal>. This has led to proprietary solutions. The most popular ones
+                depends on a <literal>bar-2.0.jar</literal>. This has led to proprietary solutions. The most popular ones
                 are Maven and Ivy. Maven is a complete build system whereas Ivy focuses solely on dependency management.
             </para>
             <para>Both approaches rely on descriptor xml files, which contains information about the dependencies of a
@@ -170,7 +170,7 @@
                 <para>An artifact only notation creates a module dependency which only downloads one artifact file. The
                     notation for such a dependency follows the pattern:
                     <literal>[group]:[artifact]:[version]@[extension]</literal>
-                    or<literal>[group]:[artifact]:[version]:[classifier]@[extension]</literal>. For example:
+                    or <literal>[group]:[artifact]:[version]:[classifier]@[extension]</literal>. For example:
                 </para>
                 <programlisting><![CDATA[
 dependencies {
@@ -202,7 +202,7 @@
             <para>This declares a dependency of your project on Groovy. Groovy itself has dependencies. But Gradle does
                 not look for an xml descriptor to figure them out but gets the information from the build file. The
                 dependencies of a client module can be normal module dependencies or artifact dependencies or another
-                client module. Have also a look at<ulink
+                client module. Have also a look at <ulink
                         url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/dependencies/ClientModule.html'>
                     org.gradle.api.dependencies.ClientModule</ulink>.
             </para>
@@ -219,7 +219,7 @@
         <section id='sub:project_dependencies'>
             <title>Project dependencies</title>
             <para>Gradle distinguishes between external dependencies and dependencies on projects which are part of the
-                same multi-project build. For the latter you can declare<emphasis>Project Dependencies</emphasis>.
+                same multi-project build. For the latter you can declare <emphasis>Project Dependencies</emphasis>.
             </para>
             <programlisting><![CDATA[
 dependencies {
@@ -226,7 +226,7 @@
     compile project(':shared')
 }
 ]]></programlisting>
-            <para>Have also a look at<ulink
+            <para>Have also a look at <ulink
                     url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/dependencies/ProjectDependency.html'>
                 org.gradle.api.dependencies.ProjectDependency</ulink>.
             </para>
@@ -256,7 +256,7 @@
           ExactPatternMatcher.INSTANCE, null));
 }
 ]]></programlisting>
-            <para>Have also a look at<ulink
+            <para>Have also a look at <ulink
                     url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/dependencies/ExcludeRuleContainer.html'>
                 org.gradle.api.dependencies.ExcludeRuleContainer</ulink>.
             </para>
@@ -290,7 +290,7 @@
                 <literal>project</literal>
                 object offers a property called
                 <literal>dependencies</literal>
-                which points to an instance of<ulink
+                which points to an instance of <ulink
                         url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/DepencencyManager.html'>
                     org.gradle.api.DependencyManager</ulink>. If you call
                 <literal>dependencies</literal>
@@ -377,7 +377,7 @@
     </section>
     <section id='sec:strategies_of_transitive_dependency_management'>
         <title>Strategies of transitive dependency management</title>
-        <para>Many projects rely on the<ulink url='http://repo1.maven.org/maven2'>Maven2 repository</ulink>. This is not
+        <para>Many projects rely on the <ulink url='http://repo1.maven.org/maven2'>Maven2 repository</ulink>. This is not
             without problems.
         </para>
         <itemizedlist>
@@ -446,7 +446,7 @@
                         this will be also possible with client modules in a future release.
                     </para>
                 </footnote>
-                Together with a continous integration server this offers a strong integration for projects with separate
+                Together with a continuous integration server this offers a strong integration for projects with separate
                 builds. As you have seen, Gradle fully supports this approach.
             </para>
         </section>
@@ -518,7 +518,7 @@
             <title>Introduction</title>
             <para>Gradle (Ivy) distinguishes between
                 <emphasis>resolvers</emphasis>
-                and<emphasis>repositories</emphasis>. A repository is the physical source for your dependencies. A
+                and <emphasis>repositories</emphasis>. A repository is the physical source for your dependencies. A
                 resolver is responsible for retrieving a dependency (usually from a repository but not necessarily). As
                 a Gradle or Ivy user,
                 <emphasis>resolvers</emphasis>
@@ -524,7 +524,7 @@
                 <emphasis>resolvers</emphasis>
                 are the objects your are working with. You can also aggregate multiple resolvers in a certain order (not
                 just linked lists). It is one of the very strengths of Ivy, how versatile you can aggregate resolvers
-                and that you can write easily your<emphasis>own</emphasis>. Gradle for example makes use of this to
+                and that you can write easily your <emphasis>own</emphasis>. Gradle for example makes use of this to
                 implement client modules. If you add a resolver, you always have to give it a name. This name is used to
                 internally address a resolver but is also used for the dependency logging. The Java plugin does not add
                 any default resolver to your projects dependency manager. Gradle offers a couple of convenience methods
@@ -556,7 +556,7 @@
 ]]></programlisting>
             <para>Quite often certain jars are not in the official Maven repository for licensing reasons (e.g. JTA).
                 But the poms are there and you want to use them. Gradle (and Ivy) use the same resolver to look for the
-                pom and the corresponding artifact. It is not possible to define a chain of resolvers, where one
+                pom and the corresponding artifact. It is now possible to define a chain of resolvers, where one
                 resolver is used for retrieving the pom and another resolver is used for retrieving the artifact. For
                 the dependencies of the artifact the chain of resolvers can be used. To solve this problem
             </para>
@@ -586,7 +586,7 @@
 ]]></programlisting>
             <para>We have 4 files in different repositories. For this example let's assume that
                 <literal>repotest-1.0.pom</literal>
-                is in the official Maven repository and that the other files are in<literal>
+                is in the official Maven repository and that the other files are in <literal>
                     http://repo.gradle.org</literal>.
             </para>
             <para>Let's define our resolvers like this:
@@ -600,7 +600,7 @@
 ]]></programlisting>
             <para>Gradle finds
                 <literal>repotest-1.0.pom</literal>
-                in the official Maven repo. After this it tries to find the corresponding artifact<literal>
+                in the official Maven repo. After this it tries to find the corresponding artifact <literal>
                     repotest-1.0.jar</literal>. It looks only in the Maven repo for this file as it expects to find pom
                 and artifact by the same resolver. The build fails.
             </para>
@@ -616,7 +616,7 @@
                 <literal>repotest-1.0.pom</literal>
                 in the Maven repo. After this it tries to find the corresponding artifact
                 <literal>repotest-1.0.jar</literal>
-                and finds it in<literal>http://repo.gradle.org</literal>. But what about<literal>
+                and finds it in <literal>http://repo.gradle.org</literal>. But what about <literal>
                     testdep-1.0.pom</literal>? As Gradle looks for poms only in the Maven repo it can't find this pom
                 file.
                 <footnote>
@@ -624,10 +624,10 @@
                         default behavior is to create internally a default pom if it can't find a pom. This default pom
                         has of course no dependencies and defines just the artifact
                         <literal>testdep-1.0.jar</literal>
-                        and would be found in<literal>http://repo.gradle.org</literal>. If you want the build to fail if
+                        and would be found in <literal>http://repo.gradle.org</literal>. If you want the build to fail if
                         a pom can't be found you must the set the
                         <literal>allownomd</literal>
-                        property of the resolver to<literal>false</literal>.
+                        property of the resolver to <literal>false</literal>.
                     </para>
                 </footnote>
             </para>
@@ -691,11 +691,11 @@
             <title>Resolver Container</title>
             <para>There are three hooks for adding resolvers. Via the resolvers assigned to the
                 <literal>classpathResolvers</literal>
-                property of the dependency manager, the<literal>compile</literal>,
+                property of the dependency manager, the <literal>compile</literal>,
                 <literal>testCompile</literal>
                 and
                 <literal>test</literal>
-                tasks retrieve there dependencies. The
+                tasks retrieve their dependencies. The
                 <literal>uploadLibs</literal>
                 and
                 <literal>uploadDists</literal>
@@ -703,7 +703,7 @@
                 <literal>uploadResolvers</literal>
                 property. You can assign one resolver to multiple hooks.
             </para>
-            <para>All of those hooks are instances of<ulink
+            <para>All of those hooks are instances of <ulink
                     url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/dependencies/ResolverContainer.html'>
                 org.gradle.api.dependencies.ResolverContainer</ulink>. This class provided methods for adding new
                 resolvers at a particular position in the resolve chain.
@@ -708,7 +708,7 @@
                 org.gradle.api.dependencies.ResolverContainer</ulink>. This class provided methods for adding new
                 resolvers at a particular position in the resolve chain.
                 <footnote>
-                    <para>Ivy power users can set<literal>dependencies.chainConfigurer = { // some statements
+                    <para>Ivy power users can set <literal>dependencies.chainConfigurer = { // some statements
                         }</literal>. This closure is applied to the
                         <literal>ChainResolver</literal>
                         containing the other Ivy resolvers.
@@ -736,7 +736,7 @@
             </itemizedlist>
             <para>If you declare a dependency like
                 <literal>junit:junit:3.8.2</literal>
-                how does Gradle finds it in the repositories. Somehow the dependency information has to be mapped to a
+                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:
                 <footnote>
@@ -773,7 +773,7 @@
                 <emphasis>Gradle</emphasis>
                 distribution. An overview of which Resolvers are offered by Ivy and thus also by Gradle can be found
                 <ulink url='http://ant.apache.org/ivy/latest-milestone/configuration/resolvers.html'>here</ulink>. With
-                Gradle you just don't configure them via xml but directly via there API.
+                Gradle you just don't configure them via xml but directly via their API.
             </para>
         </section>
     </section>
Index: trunk/src/docs/userguide/buildLifecycle.xml
===================================================================
--- trunk/src/docs/userguide/buildLifecycle.xml	(revision 1213)
+++ trunk/src/docs/userguide/buildLifecycle.xml	(working copy)
@@ -2,7 +2,7 @@
     <title>The Build Lifecycle</title>
     <para>We said earlier, that the core of Gradle is a language for dependency based programming. In Gradle terms this
         means that you can define tasks and dependencies between tasks. Gradle guarantees that those tasks are executed
-        in the order of their dependencies and are executed only once. Those tasks form an<ulink
+        in the order of their dependencies and are executed only once. Those tasks form an <ulink
                 url='http://en.wikipedia.org/wiki/Directed_acyclic_graph'>Directed Acyclic Graph</ulink>. There are
         build tools that build up such a DAG as they execute there tasks. Gradle builds the complete DAG
         <emphasis>before</emphasis>
@@ -9,7 +9,7 @@
         any task is executed. This lies at the heart of Gradle and makes many things possible which would not be
         possible otherwise.
     </para>
-    <para>Your build scripts configure this DAG. Therefore they are strictly speaking<emphasis>build configuration
+    <para>Your build scripts configure this DAG. Therefore they are strictly speaking <emphasis>build configuration
         scripts</emphasis>.
     </para>
     <section id='sec:build_phases'>
@@ -49,7 +49,7 @@
     <section id='sec:settings_file'>
         <title>Settings File</title>
         <para>Beside the build script files, Gradle defines a settings file. The settings file is determined by Gradle
-            via a naming convention. The default name for this file is<emphasis>settings.gradle</emphasis>. Later in
+            via a naming convention. The default name for this file is <emphasis>settings.gradle</emphasis>. Later in
             this chapter we explain, how Gradle looks for a settings file.
         </para>
         <para>The settings file gets executed during the initialization phase. A multiproject build must have a
Index: trunk/src/docs/userguide/warPlugin.xml
===================================================================
--- trunk/src/docs/userguide/warPlugin.xml	(revision 1213)
+++ trunk/src/docs/userguide/warPlugin.xml	(working copy)
@@ -1,7 +1,7 @@
 <chapter id='cha:the_war_plugin' xmlns:xi="http://www.w3.org/2001/XInclude">
     <title>The War Plugin</title>
     <para>The war plugin extends the JavaPlugin. It disables the default jar archive generation of the Java Plugin and
-        adds a default war archive task. Have also a look at<ulink
+        adds a default war archive task. Have also a look at <ulink
                 url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/tasks/bundling/War.html'>
             org.gradle.api.tasks.bundling.War</ulink>. \\
     </para>
@@ -15,7 +15,7 @@
             <literal>WEB-INF</literal>
             sub-directory, which again may contain a
             <literal>web.xml</literal>
-            file. Your compiled classes are compiled to<literal>WEB-INF/classes</literal>. All the dependencies of the
+            file. Your compiled classes are compiled to <literal>WEB-INF/classes</literal>. All the dependencies of the
             <literal>runtime</literal>
             <footnote>
                 <para>The
@@ -25,10 +25,10 @@
                     configuration.
                 </para>
             </footnote>
-            configuration are copied to<literal>WEB-INF/lib</literal>. The War plugin add two new dependency
+            configuration are copied to <literal>WEB-INF/lib</literal>. The War plugin add two new dependency
             configurations:
             <literal>providedCompile</literal>
-            and<literal>providedRuntime</literal>. Those new configurations have the same scope as the respective
+            and <literal>providedRuntime</literal>. Those new configurations have the same scope as the respective
             <literal>compile</literal>
             and
             <literal>runtime</literal>
@@ -36,7 +36,7 @@
             <literal>provided</literal>
             configurations work transitively. Let's say you add
             <literal>commons-httpclient:commons-httpclient:3.0</literal>
-            to any of the provided configurations. This dependency has a dependency on<literal>commons-codec</literal>.
+            to any of the provided configurations. This dependency has a dependency on <literal>commons-codec</literal>.
             This means neither
             <literal>httpclient</literal>
             nor
@@ -47,7 +47,7 @@
             <literal>compile</literal>
             configuration. If you don't want this transitive behavior, simply declare your
             <literal>provided</literal>
-            dependencies like<literal>commons-httpclient:commons-httpclient:3.0@jar</literal>.
+            dependencies like <literal>commons-httpclient:commons-httpclient:3.0@jar</literal>.
         </para>
     </section>
     <section id='sec:customizing'>
@@ -69,7 +69,7 @@
             <ulink url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/tasks/ide/eclipse/EclipseWtp.html'>
                 org.gradle.api.tasks.ide.eclipse.EclipseWtp
             </ulink>
-            has a default instance with the name<literal>eclipseWtp</literal>. It generates a
+            has a default instance with the name <literal>eclipseWtp</literal>. It generates a
             <literal>.settings/org.eclipse.wst.common.component</literal>
             file.
         </para>
Index: trunk/src/docs/userguide/multiproject.xml
===================================================================
--- trunk/src/docs/userguide/multiproject.xml	(revision 1213)
+++ trunk/src/docs/userguide/multiproject.xml	(working copy)
@@ -1,6 +1,6 @@
 <chapter id='cha: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 Gradles unique selling points. This topic is also the
+    <para>The powerful support for multi-project builds is one of Gradle's unique selling points. This topic is also the
         intellectually most challenging.
     </para>
     <section id='sec:cross_project_configuration'>
@@ -17,7 +17,7 @@
                 </footnote>
                 . This is a multi-project build with a root project
                 <literal>water</literal>
-                and a subproject<literal>bluewhale</literal>.
+                and a subproject <literal>bluewhale</literal>.
             </para>
             <programlisting><![CDATA[
 D- water
@@ -38,8 +38,8 @@
             <sampleOutput src='../../samples/userguideOutput/multiprojectFirstExample.out'/>
             <para>Gradle allows you to access any project of the multi-project build from any build script. The Project
                 API provides a method called project, which takes a path as an argument and returns the project object
-                for this path. The capability to configure a project build from any build script we call<emphasis>Cross
-                    Project Configuration</emphasis>. Gradle implements this via<emphasis>Configuration
+                for this path. The capability to configure a project build from any build script we call <emphasis>Cross
+                    Project Configuration</emphasis>. Gradle implements this via <emphasis>Configuration
                     Injection</emphasis>.
             </para>
             <para>We are not that happy with the build script of the water project. It is inconvenient to add the task
@@ -66,8 +66,8 @@
                 <literal>allprojects</literal>
                 which returns a list with the current project and all its subprojects underneath it. If you call
                 <literal>allprojects</literal>
-                with a closure, the statements of the closure are delegated to the projects associated with<literal>
-                    allprojects</literal>. You could also do an iteration via<literal>allprojects.each</literal>, but
+                with a closure, the statements of the closure are delegated to the projects associated with <literal>
+                    allprojects</literal>. You could also do an iteration via <literal>allprojects.each</literal>, but
                 that would be more verbose. \\
             </para>
             <para></para>
@@ -121,7 +121,7 @@
         </section>
         <section id='sub:project_filtering'>
             <title>Project Filtering</title>
-            <para>To show more of the power of<emphasis>Configuration Injection</emphasis>, lets' add another project
+            <para>To show more of the power of <emphasis>Configuration Injection</emphasis>, lets' add another project
                 called tropicalFish and add more behavior to the build via the build script of the water project.
             </para>
             <section id='ssub:filtering_by_name'>
@@ -175,7 +175,7 @@
                     <literal>gradefile</literal>
                     of the
                     <literal>water</literal>
-                    project we use an<literal>afterEvaluateListener</literal>. This means that the closure we are
+                    project we use an <literal>afterEvaluateListener</literal>. This means that the closure we are
                     passing gets evaluated
                     <literal>after</literal>
                     the build scripts of the subproject are evaluated. As the property
@@ -197,7 +197,7 @@
             dir and see what happens if we execute Gradle from there.
         </para>
         <sampleOutput src='../../samples/userguideOutput/multiprojectSubBuild.out'/>
-        <para>The basic rule behind Gradles behavior is simple. Gradle looks down the hierarchy, starting with the
+        <para>The basic rule behind Gradle's behavior is simple. Gradle looks down the hierarchy, starting with the
             <emphasis>current dir</emphasis>, for tasks with the name
             <literal>hello</literal>
             an executes them. One thing is very important to note. Gradle
@@ -205,7 +205,7 @@
             evaluates
             <emphasis>every</emphasis>
             project of the multi-project build and creates all existing task objects. Then, according to the task name
-            arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradles
+            arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradle's
             <emphasis>Cross Project Configuration</emphasis>
             <emphasis>every</emphasis>
             project has to be evaluated before
@@ -213,7 +213,7 @@
             task gets executed. We will have a closer look at this in the next section. Let's now have our last marine
             example. Let's add a task to
             <literal>bluewhale</literal>
-            and<literal>krill</literal>.
+            and <literal>krill</literal>.
         </para>
         <sample src='userguide/multiproject/partialTasks/water/bluewhale/build.gradle'
                 title='bluewhale -  build.gradle'/>
@@ -230,7 +230,7 @@
             <literal>water</literal>
             nor
             <literal>tropicalFish</literal>
-            have a task with the name<literal>distanceToIceberg</literal>. Gradle does not care. The simple rule
+            have a task with the name <literal>distanceToIceberg</literal>. Gradle does not care. The simple rule
             mentioned already above is: Execute all tasks down the hierarchy which have this name. Only complain if
             there is
             <emphasis>no</emphasis>
@@ -249,7 +249,7 @@
             <literal>tropicalFish</literal>
             project. We execute the
             <literal>hello</literal>
-            tasks of the<literal>water</literal>, the
+            tasks of the <literal>water</literal>, the
             <literal>krill</literal>
             and the
             <literal>tropicalFish</literal>
@@ -266,7 +266,7 @@
             <literal>water/project</literal>
             in the case of the example above.
         </para>
-        <para>The path of a task is simply its project path plus the task name. For example<literal>
+        <para>The path of a task is simply its project path plus the task name. For example <literal>
             :bluewhale:hello</literal>. Within a project you can address a task of the same project just by its name.
             This is interpreted as a relative path.
         </para>
@@ -281,8 +281,8 @@
     </section>
     <section id='sec:dependencies_which_dependencies'>
         <title>Dependencies - Which dependencies?</title>
-        <para>The examples from the last section were special, as the projects had no<emphasis>Execution
-            Dependencies</emphasis>. They had only<emphasis>Configuration Dependencies</emphasis>. Here is an example
+        <para>The examples from the last section were special, as the projects had no <emphasis>Execution
+            Dependencies</emphasis>. They had only <emphasis>Configuration Dependencies</emphasis>. Here is an example
             where this is different:
         </para>
         <section id='sub:execution_time_dependencies'>
@@ -307,8 +307,8 @@
                 <para>This did not work out. If nothing else is defined, Gradle executes the task in alphanumeric order.
                     Therefore
                     <literal>:consumer:action</literal>
-                    is executed before<literal>:producer:action</literal>. Let's try to solve this with a hack and
-                    rename the producer project to<literal>aProducer</literal>.
+                    is executed before <literal>:producer:action</literal>. Let's try to solve this with a hack and
+                    rename the producer project to <literal>aProducer</literal>.
                 </para>
                 <programlisting><![CDATA[
 D- messages
@@ -462,11 +462,11 @@
         </section>
         <section id='sub:real_life_examples'>
             <title>Real Life examples</title>
-            <para>Gradles multi-project features are driven by real life use cases. The first example for describing
+            <para>Gradle's multi-project features are driven by real life use cases. The first example for describing
                 such a use case, consists of two webapplication projects and a parent project that creates a
                 distribution out of them.
                 <footnote>
-                    <para>The real use case we had, was using<ulink url='http://lucene.apache.org/solr'/>, where you
+                    <para>The real use case we had, was using <ulink url='http://lucene.apache.org/solr'/>, where you
                         need a separate war for each index your are accessing. That was one reason why we have created a
                         distribution of webapps. The Resin servlet container allows us, to let such a distribution point
                         to a base installation of the servlet container.
@@ -472,7 +472,7 @@
                         to a base installation of the servlet container.
                     </para>
                 </footnote>
-                For the example we use only one build script and do<emphasis>cross project configuration</emphasis>.
+                For the example we use only one build script and do <emphasis>cross project configuration</emphasis>.
             </para>
             <programlisting><![CDATA[
 D- webDist
@@ -492,7 +492,7 @@
                 <literal>hello</literal>
                 task have a
                 <emphasis>configuration</emphasis>
-                dependency on<literal>webDist</literal>, as all the build logic for the webapp projects is injected by
+                dependency on <literal>webDist</literal>, as all the build logic for the webapp projects is injected by
                 <literal>webDist</literal>. The
                 <emphasis>execution</emphasis>
                 dependency is in the other direction, as
@@ -499,7 +499,7 @@
                 <literal>webDist</literal>
                 depends on the build artifacts of
                 <literal>date</literal>
-                and<literal>hello</literal>. There is even a third dependency.
+                and <literal>hello</literal>. There is even a third dependency.
                 <literal>webDist</literal>
                 has a
                 <emphasis>configuration</emphasis>
@@ -507,7 +507,7 @@
                 <literal>date</literal>
                 and
                 <literal>hello</literal>
-                because it needs to know the<literal>archivePath</literal>. But it asks for this information at
+                because it needs to know the <literal>archivePath</literal>. But it asks for this information at
                 <emphasis>execution time</emphasis>. Therefore we have no circular dependency.
             </para>
             <para>Such and other dependency patterns are daily bread in the problem space of multi-project builds. If a
@@ -514,7 +514,7 @@
                 build system does not support such patterns, you either can't solve your problem or you need to do ugly
                 hacks which are hard to maintain and massively afflict your productivity as a build master.
             </para>
-            <para>There is one more thing to note from the current example. We have used the command<literal>
+            <para>There is one more thing to note from the current example. We have used the command <literal>
                 dependOnChildren()</literal>. It is a convenience method and calls the
                 <literal>dependsOn</literal>
                 method of the parent project for every child project (not every sub project). It declares a
@@ -523,7 +523,7 @@
                 <literal>webDist</literal>
                 on
                 <literal>date</literal>
-                and<literal>hello</literal>.
+                and <literal>hello</literal>.
             </para>
             <para>Another use case would be a situation where the subprojects have a configuration
                 <emphasis>and</emphasis>
@@ -557,13 +557,13 @@
   F- settings.gradle
   F- build.gradle
 ]]></programlisting>
-        <para>We have the projects<literal>shared</literal>,
+        <para>We have the projects <literal>shared</literal>,
             <literal>api</literal>
-            and<literal>personService</literal>.
+            and <literal>personService</literal>.
             <literal>personService</literal>
             has a lib dependency on the other two projects.
             <literal>api</literal>
-            has a lib dependency on<literal>shared</literal>.
+            has a lib dependency on <literal>shared</literal>.
             <footnote>
                 <para>
                     <literal>services</literal>
@@ -590,7 +590,7 @@
             adds the jar with the classes of the other project to the classpath. It also add the dependencies of the
             other project to the classpath. So you can enter the
             <literal>api</literal>
-            folder and trigger a<literal>gradle compile</literal>. First
+            folder and trigger a <literal>gradle compile</literal>. First
             <literal>shared</literal>
             is build and then
             <literal>api</literal>
@@ -606,10 +606,10 @@
             <emphasis>additional</emphasis>
             library containing only the interfaces of the
             <literal>api</literal>
-            project. We assign this library to a new<emphasis>dependency configuration</emphasis>. For the person
+            project. We assign this library to a new <emphasis>dependency configuration</emphasis>. For the person
             service we declare that the project should be compiled only against the
             <literal>api</literal>
-            interfaces but tested with all classes from<literal>api</literal>.
+            interfaces but tested with all classes from <literal>api</literal>.
         </para>
     </section>
     <section id='sec:property_and_method_inheritance'>
@@ -618,7 +618,7 @@
             to configuration injection. But we think that the model of inheritance does not reflect the problem space of
             multi-project builds very well. In a future edition of this userguide we might write more about this.
         </para>
-        <para>Method inheritance might be interesting to use as Gradles
+        <para>Method inheritance might be interesting to use as Gradle's
             <emphasis>Configuration Injection</emphasis>
             does not support methods yet (but will in a future release.).
         </para>
Index: trunk/src/docs/userguide/buildscripts.tex
===================================================================
--- trunk/src/docs/userguide/buildscripts.tex	(revision 1213)
+++ trunk/src/docs/userguide/buildscripts.tex	(working copy)
@@ -11,7 +11,7 @@
 If you think this looks damn 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 as we think the word 'task' is more expressive than the word 'target'. Unfortunately this introduces a terminology clash with Ant, as Ant calls its commands, like \texttt{javac} or \texttt{copy}, task. So if we talk about tasks, we \textbf{always} mean Gradle tasks, which are the equivalent to Ant's targets. If we talk about Ant tasks (Ant commands), we explicitly say \textbf{ant} task.
 
 \section{Build scripts are code}
-Gradles build scripts expose to you the full power of Groovy. As an appetizer, have a look at this:
+Gradle's build scripts expose to you the full power of Groovy. As an appetizer, have a look at this:
 \codeInput{../../samples/userguide/tutorial/upper/build.gradle}
 \outputInputTutorial{upper}
 or
@@ -57,7 +57,7 @@
 % section dynamic_properties (end)
 
 \section{Ant}
-Let's talk a little bit about Gradles Ant integration. Ant can be divided into two layers. The first layer is the Ant language. It contains the syntax for the build.xml, the handling of the targets, special constructs like macrodefs, etc. Basically everything except the Ant tasks and types. Gradle does not offer any special integration for this first layer. Of course you can in your build script execute an Ant build as an external process. Your build script may contain statements like: \texttt{"ant clean compile".execute()}\footnote{In Groovy you can execute Strings. To learn more about executing external processes with Groovy have a look in GINA 9.3.2 or at the Groovy wiki}.
+Let's talk a little bit about Gradle's Ant integration. Ant can be divided into two layers. The first layer is the Ant language. It contains the syntax for the build.xml, the handling of the targets, special constructs like macrodefs, etc. Basically everything except the Ant tasks and types. Gradle does not offer any special integration for this first layer. Of course you can in your build script execute an Ant build as an external process. Your build script may contain statements like: \texttt{"ant clean compile".execute()}\footnote{In Groovy you can execute Strings. To learn more about executing external processes with Groovy have a look in GINA 9.3.2 or at the Groovy wiki}.
 
 The second layer of Ant is its wealth of Ant tasks and types, like \texttt{javac}, \texttt{copy} or \texttt{jar}. For this layer Gradle provides excellent integration simply by relying on Groovy. Groovy is shipped with the fantastic \texttt{AntBuilder}. Using Ant tasks from Gradle is as convenient and more powerful than using Ant tasks from a \texttt{build.xml} file. Let's look at an example:
 \codeInput{../../samples/userguide/tutorial/antChecksum/build.gradle}
Index: trunk/src/docs/userguide/tasks.xml
===================================================================
--- trunk/src/docs/userguide/tasks.xml	(revision 1213)
+++ trunk/src/docs/userguide/tasks.xml	(working copy)
@@ -20,7 +20,7 @@
         <programlisting><![CDATA[
 createTask('resources', type: Resources)
 ]]></programlisting>
-        <para>The resources task provides an API to configure it. See<ulink
+        <para>The resources task provides an API to configure it. See <ulink
                 url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/tasks/Resources.html'>Resources Task API</ulink>.
             If you create the resources task like this, it has no default behavior.
             <footnote>
@@ -48,7 +48,7 @@
 ]]></programlisting>
         <para>You might know this approach from the Hibernates Criteria Query API or JMock. Of course the API of a task
             has to support this. The from, to and includes methods all return an instance of the resources object. All
-            of Gradles build-in tasks usually support this configuration style.
+            of Gradle's build-in tasks usually support this configuration style.
         </para>
         <para>But there is yet another way of configuring the resources task. It also preserves the context and it
             possibly offers the best readability. It is usually our favorite.
@@ -63,7 +63,7 @@
 ]]></programlisting>
         <para>This works for
             <emphasis>any</emphasis>
-            task. Line 2 of the example is just a shortcut for<literal>task("resources")</literal>. It is important to
+            task. Line 2 of the example is just a shortcut for <literal>task("resources")</literal>. It is important to
             note that if you pass a closure to the
             <literal>task</literal>
             method, this closure is applied for
@@ -117,7 +117,7 @@
             <literal>Task</literal>
             objects, which are then treated as dependencies of the task. The following example adds a dependency from
             <literal>taskX</literal>
-            to all the tasks in the project whose name starts with<literal>lib</literal>:
+            to all the tasks in the project whose name starts with <literal>lib</literal>:
         </para>
         <sample src='userguide/tasks/addDependencyUsingClosure/build.gradle'
                 title='Sample userguide/tasks/addDependencyUsingClosure/build.gradle'/>
@@ -148,7 +148,7 @@
             <emphasis>Resources</emphasis>
             looks like a mixture between an Ant target and an Ant task. And this is actually the case. The separation
             that Ant does between tasks and targets is not done by Gradle. The simple Gradle tasks are like Ant's
-            targets and the enhanced Gradle tasks also include the Ant task aspects. All of Gradles tasks share a common
+            targets and the enhanced Gradle tasks also include the Ant task aspects. All of Gradle's tasks share a common
             API and you can create dependencies between them. Such a task might be nicer to configure than an Ant task.
             It makes full use of the type system, is more expressive and easier to maintain.
         </para>
Index: trunk/src/docs/userguide/organizeBuildLogic.xml
===================================================================
--- trunk/src/docs/userguide/organizeBuildLogic.xml	(revision 1213)
+++ trunk/src/docs/userguide/organizeBuildLogic.xml	(working copy)
@@ -14,7 +14,7 @@
     </para>
     <section id='sec:build_sources'>
         <title>Build Sources</title>
-        <para>If you run Gradle, it checks for the existence of a folder called<literal>buildSrc</literal>. Just put
+        <para>If you run Gradle, it checks for the existence of a folder called <literal>buildSrc</literal>. Just put
             your build source code in this folder and stick to the layout convention for a Java/Groovy project (see
             <xref linkend='javalayout'/>). Gradle then automatically compiles and tests this code and puts it in
             the classpath of your build script. You don't need to provide any further instruction. For multi-project
@@ -44,7 +44,7 @@
             <xref linkend='sec:how_to_declare_your_dependencies'/>
             (except project dependencies). There is
             <emphasis>no</emphasis>
-            need to provide a<emphasis>dependency configuration</emphasis>(e.g.<literal>compile</literal>). For
+            need to provide a <emphasis>dependency configuration</emphasis>(e.g.<literal>compile</literal>). For
             multi-project builds dependencies declared in the
             <literal>settings.gradle</literal>
             file of the root project, are available to all build scripts of the sub-projects.
@@ -59,7 +59,7 @@
                     task need the
                     <emphasis>same</emphasis>
                     library you would have to define it two times. In such a case it would be nice, if Ant's optional
-                    task would automatically pickup the classpath defined in the<literal>gradesettings</literal>.
+                    task would automatically pickup the classpath defined in the <literal>gradesettings</literal>.
                 </para>
             </footnote>
         </para>
Index: trunk/src/docs/userguide/gradleWrapper.xml
===================================================================
--- trunk/src/docs/userguide/gradleWrapper.xml	(revision 1213)
+++ trunk/src/docs/userguide/gradleWrapper.xml	(working copy)
@@ -45,7 +45,7 @@
     </para>
     <section id='sec:configuration'>
         <title>Configuration</title>
-        <para>If you run Gradle with<literal>gradlew</literal>, Gradle checks if a Gradle distribution for the wrapper
+        <para>If you run Gradle with <literal>gradlew</literal>, Gradle checks if a Gradle distribution for the wrapper
             is available. If not it tries to download it, otherwise it delegates to the
             <literal>gradle</literal>
             command of this distribution with all the arguments passed originally to the
@@ -59,7 +59,7 @@
             wrapper distribution at the specified place.
         </para>
         <para>All the configuration options have defaults except the version of the wrapper distribution. If you don't
-            want any download to happen when your project is build via<literal>gradlew</literal>, simply add the Gradle
+            want any download to happen when your project is build via <literal>gradlew</literal>, simply add the Gradle
             distribution zip to your version control at the location specified by your wrapper configuration.
         </para>
         <para>For the details on how to configure the wrapper, see
@@ -72,7 +72,7 @@
         <title>Unix file permissions</title>
         <para>The Wrapper task adds appropriate file permissions to allow the execution for the gradlew *NIX command.
             Subversion preserves this file permission. We are not sure how other version control systems deal with this.
-            What should always work is to execute<literal>sh gradlew</literal>.
+            What should always work is to execute <literal>sh gradlew</literal>.
         </para>
     </section>
     <section id='sec:environment_variable'>
@@ -94,7 +94,7 @@
             </thead>
             <tr>
                 <td>GRADLE_WRAPPER_ALWAYS_UNPACK</td>
-                <td>If set to<literal>true</literal>, the distribution directory gets always deleted when
+                <td>If set to <literal>true</literal>, the distribution directory gets always deleted when
                     <literal>gradlew</literal>
                     is run and the distribution zip is freshly unpacked. If the zip is not there, Gradle tries to
                     download it.
@@ -102,7 +102,7 @@
             </tr>
             <tr>
                 <td>GRADLE_WRAPPER_ALWAYS_DOWNLOAD</td>
-                <td>If set to<literal>true</literal>, the distribution directory and the distribution zip gets always
+                <td>If set to <literal>true</literal>, the distribution directory and the distribution zip gets always
                     deleted when
                     <literal>gradlew</literal>
                     is run and the distribution zip is freshly downloaded.
Index: trunk/src/docs/userguide/multiproject.tex
===================================================================
--- trunk/src/docs/userguide/multiproject.tex	(revision 1213)
+++ trunk/src/docs/userguide/multiproject.tex	(working copy)
@@ -2,7 +2,7 @@
 \chapter{Multi-project builds} % (fold)
 \label{cha:multi_project_builds}
 
-The powerful support for multi-project builds is one of Gradles unique selling points. This topic is also the intellectually most challenging.
+The powerful support for multi-project builds is one of Gradle's unique selling points. This topic is also the intellectually most challenging.
 \section{Cross Project Configuration} % (fold)
 \label{sec:cross_project_configuration}
 Let's start with a very simple multi-project build. After all Gradle is a general purpose build tool at its core. So the projects don't have to be java projects. Our first examples are about marine life. 
@@ -158,7 +158,7 @@
 \label{sec:execution_rules_for_multi_project_builds}
 When we have executed the \texttt{hello} task from the root project dir things behaved in an intuitive way. All the \texttt{hello} tasks of the different projects were executed. Let's switch to the \texttt{bluewhale} dir and see what happens if we execute Gradle from there. 
 \outputInputGradle[current dir: userguide/multiproject/partialTasks/water/bluewhale]{../../samples/userguideOutput/multiprojectSubBuild.out}
-The basic rule behind Gradles behavior is simple. Gradle looks down the hierarchy, starting with the \emph{current dir}, for tasks with the name \texttt{hello} an executes them. One thing is very important to note. Gradle \emph{always} evaluates \emph{every} project of the multi-project build and creates all existing task objects. Then, according to the task name arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradles \emph{Cross Project Configuration} \emph{every} project has to be evaluated before \emph{any} task gets executed. We will have a closer look at this in the next section. Let's now have our last marine example. Let's add a task to \texttt{bluewhale} and \texttt{krill}.
+The basic rule behind Gradle's behavior is simple. Gradle looks down the hierarchy, starting with the \emph{current dir}, for tasks with the name \texttt{hello} an executes them. One thing is very important to note. Gradle \emph{always} evaluates \emph{every} project of the multi-project build and creates all existing task objects. Then, according to the task name arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradle's \emph{Cross Project Configuration} \emph{every} project has to be evaluated before \emph{any} task gets executed. We will have a closer look at this in the next section. Let's now have our last marine example. Let's add a task to \texttt{bluewhale} and \texttt{krill}.
 \codeGradleFile[bluewhale - ]{../../samples/userguide/multiproject/partialTasks/water/bluewhale/build.gradle}
 \codeGradleFile[krill - ]{../../samples/userguide/multiproject/partialTasks/water/krill/build.gradle}
 \outputInputGradle[userguide/multiproject/partialTasks/water]{../../samples/userguideOutput/multiprojectPartialTasks.out}
@@ -286,7 +286,7 @@
 
 \subsection{Real Life examples} % (fold)
 \label{sub:real_life_examples}
-Gradles multi-project features are driven by real life use cases. The first example for describing such a use case, consists of two webapplication projects and a parent project that creates a distribution out of them.\footnote{The real use case we had, was using \url{http://lucene.apache.org/solr}, where you need a separate war for each index your are accessing. That was one reason why we have created a distribution of webapps. The Resin servlet container allows us, to let such a distribution point to a base installation of the servlet container.} For the example we use only one build script and do \emph{cross project configuration}.
+Gradle's multi-project features are driven by real life use cases. The first example for describing such a use case, consists of two webapplication projects and a parent project that creates a distribution out of them.\footnote{The real use case we had, was using \url{http://lucene.apache.org/solr}, where you need a separate war for each index your are accessing. That was one reason why we have created a distribution of webapps. The Resin servlet container allows us, to let such a distribution point to a base installation of the servlet container.} For the example we use only one build script and do \emph{cross project configuration}.
 \begin{Verbatim}[frame=single,label=Project Tree]
 D- webDist
   F- settings.gradle
@@ -341,7 +341,7 @@
 \label{sec:property_and_method_inheritance}
 Properties and methods declared in a project are inherited to all its subprojects. This is an alternative to configuration injection. But we think that the model of inheritance does not reflect the problem space of multi-project builds very well. In a future edition of this userguide we might write more about this. 
 
-Method inheritance might be interesting to use as Gradles \emph{Configuration Injection} does not support methods yet (but will in a future release.).
+Method inheritance might be interesting to use as Gradle's \emph{Configuration Injection} does not support methods yet (but will in a future release.).
 
 You might be wondering why we have implemented a feature we obviously don't like that much. One reason is that it is offered by other tools and we want to have the check mark in a feature comparison :). And we like to offer our users a choice.
 % section property_and_method_inheritance (end)
Index: trunk/src/docs/userguide/maven.tex
===================================================================
--- trunk/src/docs/userguide/maven.tex	(revision 1213)
+++ trunk/src/docs/userguide/maven.tex	(working copy)
@@ -3,7 +3,7 @@
 \label{cha:interacting_with_maven_repositories}
 \section{Introduction} % (fold)
 \label{sec:introduction}
-With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradles deployment is 100 percent Maven compatible as we use the native Maven Ant tasks under the hood.
+With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradle's deployment is 100 percent Maven compatible as we use the native Maven Ant tasks under the hood.
 
 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, from the dependency information it has. 
 % section introduction (end)
@@ -20,7 +20,7 @@
 \end{Verbatim}
 That is all. Calling the \texttt{uploadLibs} task will generate the pom and deploys the artifact and the pom to the specified repository. 
 
-There is some more work to do, if you need support for other protocols than \texttt{file}. In this case the native Maven code we delegate to needs additional libraries. Those libraries depend on the protocol you need. The available protocols and the corresponding libraries are listed in table \ref{wagonLibs}. Those libraries have again transitive dependencies which have transitive dependencies. You need to provide the complete list of those to the MavenDeployer{\footnote{It is planned for a future release to provide out-of-the-box support for this}}. The easiest way to do this is the following:
+There is some more work to do if you need support for protocols other than \texttt{file}. In this case the native Maven code we delegate to needs additional libraries. Those libraries depend on the protocol you need. The available protocols and the corresponding libraries are listed in table \ref{wagonLibs}. Those libraries have again transitive dependencies which have transitive dependencies. You need to provide the complete list of those to the MavenDeployer{\footnote{It is planned for a future release to provide out-of-the-box support for this}}. The easiest way to do this is the following:
 \begin{Verbatim}
 dependencies {
     addConfiguration('deployerJars')
@@ -156,7 +156,7 @@
 	\item A dependency belongs to only one configuration: The first thing Gradle checks is whether there is a mapping for this configuration. If there is none, the dependency is by default not added to the pom. By setting the  mapping property \texttt{includeUnmappedConfigurations} to true, such a dependency will be added. If the configuration is mapped, the corresponding scope is obvious and the dependency is added.
 	\item A dependency belongs to more than one mapped configuration: If the mapped configurations map to the same scope the situation is clear. If the mapped configurations map to different scopes the configuration mapping with the highest priority is chosen. If there is more than one configuration with a highest priority and they map to different scopes an exception is thrown.
 \end{itemize}
-Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in the Gradle exlude rule the organisation as well as the module name is specified (as Maven needs both in contrast to Ivy). Right now Global Excludes are not converted to the Maven Pom. 
+Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in the Gradle exclude rule the organisation as well as the module name is specified (as Maven needs both in contrast to Ivy). Right now Global Excludes are not converted to the Maven Pom. 
 
 \subsection{Planned future features} % (fold)
 \label{sub:planned_future_features}
Index: trunk/src/docs/userguide/maven.xml
===================================================================
--- trunk/src/docs/userguide/maven.xml	(revision 1213)
+++ trunk/src/docs/userguide/maven.xml	(working copy)
@@ -3,7 +3,7 @@
     <section id='sec:introduction'>
         <title>Introduction</title>
         <para>With Gradle you can deploy to remote Maven repositories or install to your local Maven repository. This
-            includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradles deployment is
+            includes all Maven metadata manipulation and works also for Maven snapshots. In fact, Gradle's deployment is
             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
@@ -26,7 +26,7 @@
             <literal>uploadLibs</literal>
             task will generate the pom and deploys the artifact and the pom to the specified repository.
         </para>
-        <para>There is some more work to do, if you need support for other protocols than<literal>file</literal>. In
+        <para>There is some more work to do if you need support for protocols other than <literal>file</literal>. In
             this case the native Maven code we delegate to needs additional libraries. Those libraries depend on the
             protocol you need. The available protocols and the corresponding libraries are listed in <xref
                     linkend='wagonLibs'/>. Those libraries have again transitive dependencies which have transitive
@@ -201,7 +201,7 @@
                 task. This install task depends on the
                 <literal>libs</literal>
                 task of the Java plugin. It installs your libraries to your local Maven repository. If the default
-                location for the local repository is redefined in a Maven<literal>settings.xml</literal>, this is
+                location for the local repository is redefined in a Maven <literal>settings.xml</literal>, this is
                 considered by this task.
             </para>
         </section>
@@ -309,7 +309,7 @@
                 </listitem>
             </itemizedlist>
             <para>Gradle exclude rules are converted to Maven excludes if possible. Such a conversion is possible if in
-                the Gradle exlude rule the organisation as well as the module name is specified (as Maven needs both in
+                the Gradle exclude rule the organisation as well as the module name is specified (as Maven needs both in
                 contrast to Ivy). Right now Global Excludes are not converted to the Maven Pom.
             </para>
         </section>
Index: trunk/src/docs/userguide/javaPlugin.xml
===================================================================
--- trunk/src/docs/userguide/javaPlugin.xml	(revision 1213)
+++ trunk/src/docs/userguide/javaPlugin.xml	(working copy)
@@ -10,7 +10,7 @@
         <footnote>
             <para>The
                 <emphasis>buildDir</emphasis>
-                property is a property of the project object. It defaults to<literal>build</literal>.
+                property is a property of the project object. It defaults to <literal>build</literal>.
             </para>
         </footnote>
         Gradle's conventions contain a convention for the directory hierarchy as well as conventions for the element
@@ -16,7 +16,7 @@
         Gradle's conventions contain a convention for the directory hierarchy as well as conventions for the element
         names of the hierarchy. For example the
         <literal>srcDirs</literal>
-        are relative to the<literal>srcRoot</literal>. Therefore
+        are relative to the <literal>srcRoot</literal>. Therefore
         <literal>srcDirs</literal>
         is a read-only property. If you want to change the name of the source dirs you need to do this via the
         <literal>srcDirNames</literal>
@@ -22,11 +22,11 @@
         <literal>srcDirNames</literal>
         property. But the paths you specify here are
         <emphasis>relative</emphasis>
-        to the<literal>srcRoot</literal>. This has the advantage to make bulk changes easy. If you change
+        to the <literal>srcRoot</literal>. This has the advantage to make bulk changes easy. If you change
         <literal>srcRoot</literal>
         from
         <literal>src</literal>
-        to<literal>source</literal>, this automatically applies to all directory properties which are relative to
+        to <literal>source</literal>, this automatically applies to all directory properties which are relative to
         <literal>srcRoot</literal>. As this also introduces an inflexibility, we have additional floating dirs, which
         are not bound to any hierarchy (see <xref linkend='javaconventionFloatingDir'/>). For example code
         generation tool could make use of this, by adding a source dir which is located in the build folder.
@@ -367,7 +367,7 @@
             <literal>clean</literal>
             and
             <literal>javadoc</literal>
-            which does not depends on<literal>init</literal>).
+            which does not depends on <literal>init</literal>).
         </para>
     </section>
     <section id='sec:javadoc'>
@@ -406,7 +406,7 @@
             property. This property is mapped to the
             <literal>buildDir</literal>
             property of the project. In future releases there will be more control of what gets deleted. If you need
-            more control now, you can use the<emphasis>Ant delete task</emphasis>.
+            more control now, you can use the <emphasis>Ant delete task</emphasis>.
         </para>
     </section>
     <section id='sec:resources'>
@@ -415,7 +415,7 @@
             <emphasis>Resources</emphasis>
             task has two instances,
             <literal>resources</literal>
-            and<literal>testResources</literal>.
+            and <literal>testResources</literal>.
         </para>
         <table>
             <title>Java Convention Object - Resource Properties</title>
@@ -463,7 +463,7 @@
             <emphasis>Compile</emphasis>
             task has two instances,
             <literal>compile</literal>
-            and<literal>testCompile</literal>.
+            and <literal>testCompile</literal>.
         </para>
         <table>
             <title>Java Convention Object - Compile Properties</title>
@@ -588,7 +588,7 @@
             <emphasis>.class</emphasis>
             files. The default include is
             <literal>**/*Tests.class", "**/*Test.class</literal>
-            and the default exclude is<literal>**/Abstract*.class</literal>.
+            and the default exclude is <literal>**/Abstract*.class</literal>.
         </para>
         <para>The test task delegates to Ants junit task. TestNG is not supported yet. You can expect TestNG support in
             one of our next releases.
@@ -600,7 +600,7 @@
             <emphasis>Bundle</emphasis>
             task has two instances,
             <literal>libs</literal>
-            and<literal>dists</literal>. The Bundle task is a special animal. It is a container for archive tasks (jar,
+            and <literal>dists</literal>. The Bundle task is a special animal. It is a container for archive tasks (jar,
             zip, ...).
         </para>
         <table>
@@ -643,7 +643,7 @@
                 <literal>libs</literal>
                 task. The task name is by default
                 <literal>archive_jar</literal>
-                and can of course be manipulated by this name. This jar contains the content of the<literal>
+                and can of course be manipulated by this name. This jar contains the content of the <literal>
                     classesDir</literal>. This is the behavior your are used from Maven. If you are happy with that you
                 usually don't have to touch this task. Except if you want to change the names of the generated archives.
             </para>
@@ -694,7 +694,7 @@
             </para>
             <sample src='userguide/tutorial/zip/build.gradle' title='Sample userguide/tutorial/zip/build.gradle'/>
             <sampleOutput src='zip.out'/>
-            <para>This adds an archive task with the name<literal>archive_zip</literal>. It is important to distinguish
+            <para>This adds an archive task with the name <literal>archive_zip</literal>. It is important to distinguish
                 between the name of the archive task and the name of the archive generated by the archive task. The name
                 of the generated archive file is by default the name of the project. The default for naming generated
                 archives can be changed with the
@@ -833,7 +833,7 @@
         </para>
         <section id='sub:common_properties'>
             <title>Common Properties</title>
-            <para>The name of the generated archive is assembled from the task properties<literal>baseName</literal>,
+            <para>The name of the generated archive is assembled from the task properties <literal>baseName</literal>,
                 <literal>classifier</literal>
                 and
                 <literal>extension</literal>
@@ -910,7 +910,7 @@
         <section id='sub:merging'>
             <title>Merging</title>
             <para>If you want to merge the content of other archives into the archive to be generated Gradle offers you
-                two methods. One is<literal>merge</literal>:
+                two methods. One is <literal>merge</literal>:
             </para>
             <programlisting><![CDATA[
 myZipTask.merge('path1/otherArchive1.zip', 'path2/otherArchive.tar.gz')
@@ -929,8 +929,8 @@
             <para>Under the hood Gradle scans the extension of the archives to be merged. According to the extension, it
                 creates a
                 <literal>ZipFileSet</literal>
-                or<literal>TarFileSet</literal>. The closure is applied to this newly created file container. \\ There
-                is another method for merging called<literal>mergeGroup</literal>.
+                or <literal>TarFileSet</literal>. The closure is applied to this newly created file container. \\ There
+                is another method for merging called <literal>mergeGroup</literal>.
             </para>
             <programlisting><![CDATA[
 myZipTask.mergeGroup('path_to_dir_with_archives') {
@@ -949,7 +949,7 @@
             <title>Manifest</title>
             <para>The convention object of the JavaPlugin has a
                 <literal>manifest</literal>
-                property pointing to an instance of<ulink
+                property pointing to an instance of <ulink
                         url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/tasks/bundling/GradleManifest.html'>
                     org.gradle.api.bundling.GradleManifest</ulink>. With this
                 <literal>GradleManifest</literal>
@@ -996,7 +996,7 @@
             <emphasis>Upload</emphasis>
             task has two instances,
             <literal>uploadLibs</literal>
-            and<literal>uploadDists</literal>. An easy way of describing there behavior, is that all archives added to
+            and <literal>uploadDists</literal>. An easy way of describing there behavior, is that all archives added to
             the
             <literal>libs</literal>
             and
@@ -1018,7 +1018,7 @@
                 <ulink url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/tasks/ide/eclipse/EclipseClasspath.html'>
                     org.gradle.api.tasks.ide.eclipse.EclipseClasspath
                 </ulink>
-                has a default instance with the name<literal>eclipseCp</literal>. It generates a
+                has a default instance with the name <literal>eclipseCp</literal>. It generates a
                 <literal>.classpath</literal>
                 file.
             </para>
@@ -1061,7 +1061,7 @@
                 <ulink url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/tasks/ide/eclipse/EclipseProject.html'>
                     org.gradle.api.tasks.ide.eclipse.EclipseProject
                 </ulink>
-                has a default instance with the name<literal>eclipseProject</literal>. It generates a
+                has a default instance with the name <literal>eclipseProject</literal>. It generates a
                 <literal>.project</literal>
                 file.
             </para>
Index: trunk/src/docs/userguide/commandLine.xml
===================================================================
--- trunk/src/docs/userguide/commandLine.xml	(revision 1213)
+++ trunk/src/docs/userguide/commandLine.xml	(working copy)
@@ -131,6 +131,6 @@
         </tr>
 
     </table>
-    <para>The same information is printed to the console when you execute<literal>gradle -h</literal>.
+    <para>The same information is printed to the console when you execute <literal>gradle -h</literal>.
     </para>
 </appendix>
Index: trunk/src/docs/userguide/buildscripts.xml
===================================================================
--- trunk/src/docs/userguide/buildscripts.xml	(revision 1213)
+++ trunk/src/docs/userguide/buildscripts.xml	(working copy)
@@ -10,7 +10,7 @@
     <section>
         <title>Hello World</title>
         <para>In Gradle everything revolves around tasks. The tasks for your build are defined in the build script. To
-            try this out, create the following build script named<literal>build.gradle</literal>.
+            try this out, create the following build script named <literal>build.gradle</literal>.
         </para>
         <sample src='userguide/tutorial/hello/build.gradle' title='Sample userguide/tutorial/hello/build.gradle'/>
         <para>Enter with your shell into the containing directory and execute the build script
@@ -36,7 +36,7 @@
             terminology to Ant as we think the word 'task' is more expressive than the word 'target'. Unfortunately this
             introduces a terminology clash with Ant, as Ant calls its commands, like
             <literal>javac</literal>
-            or<literal>copy</literal>, task. So if we talk about tasks, we
+            or <literal>copy</literal>, task. So if we talk about tasks, we
             <emphasis>always</emphasis>
             mean Gradle tasks, which are the equivalent to Ant's targets. If we talk about Ant tasks (Ant commands), we
             explicitly say
@@ -46,7 +46,7 @@
     </section>
     <section>
         <title>Build scripts are code</title>
-        <para>Gradles build scripts expose to you the full power of Groovy. As an appetizer, have a look at this:
+        <para>Gradle's build scripts expose to you the full power of Groovy. As an appetizer, have a look at this:
         </para>
         <sample src='userguide/tutorial/upper/build.gradle' title='Sample userguide/tutorial/upper/build.gradle'/>
         <sampleOutput src='upper.out'/>
@@ -86,7 +86,7 @@
     </section>
     <section>
         <title>Manipulating existing tasks</title>
-        <para>Once tasks are created they can be accessed via an<emphasis>API</emphasis>. This is different to Ant. For
+        <para>Once tasks are created they can be accessed via an <emphasis>API</emphasis>. This is different to Ant. For
             example you can create additional dependencies.
         </para>
         <sample src='userguide/tutorial/dynamicDepends/build.gradle'
@@ -130,7 +130,7 @@
     </section>
     <section>
         <title>Ant</title>
-        <para>Let's talk a little bit about Gradles Ant integration. Ant can be divided into two layers. The first layer
+        <para>Let's talk a little bit about Gradle's Ant integration. Ant can be divided into two layers. The first layer
             is the Ant language. It contains the syntax for the build.xml, the handling of the targets, special
             constructs like macrodefs, etc. Basically everything except the Ant tasks and types. Gradle does not offer
             any special integration for this first layer. Of course you can in your build script execute an Ant build as
@@ -143,10 +143,10 @@
             </footnote>
             .
         </para>
-        <para>The second layer of Ant is its wealth of Ant tasks and types, like<literal>javac</literal>,
+        <para>The second layer of Ant is its wealth of Ant tasks and types, like <literal>javac</literal>,
             <literal>copy</literal>
-            or<literal>jar</literal>. For this layer Gradle provides excellent integration simply by relying on Groovy.
-            Groovy is shipped with the fantastic<literal>AntBuilder</literal>. Using Ant tasks from Gradle is as
+            or <literal>jar</literal>. For this layer Gradle provides excellent integration simply by relying on Groovy.
+            Groovy is shipped with the fantastic <literal>AntBuilder</literal>. Using Ant tasks from Gradle is as
             convenient and more powerful than using Ant tasks from a
             <literal>build.xml</literal>
             file. Let's look at an example:
@@ -196,7 +196,7 @@
         <sample src='userguide/tutorial/defaultTasks/build.gradle'
                 title='Sample userguide/tutorial/defaultTasks/build.gradle'/>
         <sampleOutput src='defaultTasks.out'/>
-        <para>This is equivalent to running<literal>gradle clean run</literal>. In a multi-project build every
+        <para>This is equivalent to running <literal>gradle clean run</literal>. In a multi-project build every
             subproject can have its own specific default tasks. If a subproject does not specify default tasks, the
             default tasks of the parent project are used (if defined).
         </para>
Index: trunk/src/docs/userguide/ideSupport.tex
===================================================================
--- trunk/src/docs/userguide/ideSupport.tex	(revision 1213)
+++ trunk/src/docs/userguide/ideSupport.tex	(working copy)
@@ -3,9 +3,9 @@
 \label{cha:ide_support}
 \section{IntelliJ} % (fold)
 \label{sec:intellij}
-Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradles build script\footnote{Gradle is build with Gradle} has also been developed with the support of this IDE. IntelliJ allows you to define any filepattern to be interpreted as a Groovy script. In the case of Gradle you can define such a pattern for \emph{build.gradle} and \emph{settings.gradle}. This will already help very much. What is missing is the classpath to the Gradle binaries to offer content assistance for the Gradle classes. You might add the gradle jar (which you can find in your distribution) to your project's classpath. It does not really belong there, but if you do this you have a fantastic IDE support for developing Gradle scripts. Of course if you use additional libraries for your build scripts they would further pollute your project classpath.  
+Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradle's build script\footnote{Gradle is build with Gradle} has also been developed with the support of this IDE. IntelliJ allows you to define any filepattern to be interpreted as a Groovy script. In the case of Gradle you can define such a pattern for \emph{build.gradle} and \emph{settings.gradle}. This will already help very much. What is missing is the classpath to the Gradle binaries to offer content assistance for the Gradle classes. You might add the gradle jar (which you can find in your distribution) to your project's classpath. It does not really belong there, but if you do this you have a fantastic IDE support for developing Gradle scripts. Of course if you use additional libraries for your build scripts they would further pollute your project classpath.  
 
-We hope that in the future \texttt{build.gradles} get special treatment by IntelliJ and you will be able to define a specific classpath for them.
+We hope that in the future \texttt{build.Gradle's} get special treatment by IntelliJ and you will be able to define a specific classpath for them.
 % section intellij (end)
 
 \section{Eclipse} % (fold)
Index: trunk/src/docs/userguide/logging.xml
===================================================================
--- trunk/src/docs/userguide/logging.xml	(revision 1213)
+++ trunk/src/docs/userguide/logging.xml	(working copy)
@@ -4,7 +4,7 @@
         by this. On the other hand you need the relevant information for figuring out if things have gone wrong. Gradle
         has added to log-levels to the ones normally used. Those levels are
         <emphasis>QUIET</emphasis>
-        and<emphasis>LIFECYCLE</emphasis>. The latter is the default and is telling you just what task is getting
+        and <emphasis>LIFECYCLE</emphasis>. The latter is the default and is telling you just what task is getting
         executed or skipped.
     </para>
     <section id='sec:choosing_a_log_level'>
@@ -14,7 +14,7 @@
             <literal>WARN</literal>
             and
             <emphasis>ERROR</emphasis>
-            levels are included in all the other levels, except<emphasis>QUIET</emphasis>, where only
+            levels are included in all the other levels, except <emphasis>QUIET</emphasis>, where only
             <emphasis>ERROR</emphasis>
             is included. In <xref linkend='stacktraces'/> you find the command line switches for stacktrace
             logging.
@@ -106,9 +106,9 @@
             <emphasis>ERROR</emphasis>
             level. This behavior is configurable. Gradle provides a couple of switches for this. To change the log
             level, standard out is redirected to, when your build script gets evaluated, the project object offers a
-            method called<ulink url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/Project.html'>
+            method called <ulink url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/Project.html'>
                 Project#captureStandardOutput</ulink>. To change the log level for standard out during task execution,
-            tasks offer a method also with the name<ulink
+            tasks offer a method also with the name <ulink
                     url='http://www.gradle.org/JAVADOCDIR/org/gradle/api/Task.html'>Task#captureStandardOutput</ulink>.
             Tasks and projects also offer a method
             <literal>disableStandardOutputCapture</literal>
@@ -128,7 +128,7 @@
             treats them as log levels. In a future version of Gradle we want to provide a logger which provides
             additional log methods
             <literal>quiet</literal>
-            and<literal>lifecycle</literal>.
+            and <literal>lifecycle</literal>.
         </para>
         <para>You can also hook into Gradle's logging system from within other classes (classes from the buildSrc
             directory for example). Simply use a slf4j logger.
Index: trunk/src/docs/userguide/tasks.tex
===================================================================
--- trunk/src/docs/userguide/tasks.tex	(revision 1213)
+++ trunk/src/docs/userguide/tasks.tex	(working copy)
@@ -24,7 +24,7 @@
 resources.from(file('resources')).to(file('target')).
 	includes('**/*.txt', '**/*.xml', '**/*.properties')	
 \end{Verbatim}
-You might know this approach from the Hibernates Criteria Query API or JMock. Of course the API of a task has to support this. The from, to and includes methods all return an instance of the resources object. All of Gradles build-in tasks usually support this configuration style.
+You might know this approach from the Hibernates Criteria Query API or JMock. Of course the API of a task has to support this. The from, to and includes methods all return an instance of the resources object. All of Gradle's build-in tasks usually support this configuration style.
 
 But there is yet another way of configuring the resources task. It also preserves the context and it possibly offers the best readability. It is usually our favorite.
 \begin{Verbatim}
@@ -79,9 +79,9 @@
 
 \section{Summary} % (fold)
 \label{sec:the_idea_behind_gradle_tasks}
-If you are coming from Ant, such an enhanced Gradle task as \emph{Resources} looks like a mixture between an Ant target and an Ant task. And this is actually the case. The separation that Ant does between tasks and targets is not done by Gradle. The simple Gradle tasks are like Ant's targets and the enhanced Gradle tasks also include the Ant task aspects. All of Gradles tasks share a common API and you can create dependencies between them. Such a task might be nicer to configure than an Ant task. It makes full use of the type system, is more expressive and easier to maintain.
+If you are coming from Ant, such an enhanced Gradle task as \emph{Resources} looks like a mixture between an Ant target and an Ant task. And this is actually the case. The separation that Ant does between tasks and targets is not done by Gradle. The simple Gradle tasks are like Ant's targets and the enhanced Gradle tasks also include the Ant task aspects. All of Gradle's tasks share a common API and you can create dependencies between them. Such a task might be nicer to configure than an Ant task. It makes full use of the type system, is more expressive and easier to maintain.
 
-% You might be wondering why the Resources task you have created above is not initialized with any default values. After all Gradle claims to offer build-by-convention. But which default values? The one we use for Java Projects? Or the one we use for other project types? What we have done above is to use a Gradle task in a stand alone fashion. It is open for anything. How Gradles tasks are integrated into a build-by-convention mechanism is what we are going to show in the next chapter.
+% You might be wondering why the Resources task you have created above is not initialized with any default values. After all Gradle claims to offer build-by-convention. But which default values? The one we use for Java Projects? Or the one we use for other project types? What we have done above is to use a Gradle task in a stand alone fashion. It is open for anything. How Gradle's tasks are integrated into a build-by-convention mechanism is what we are going to show in the next chapter.
 
 % section the_idea_behind_gradle_tasks (end)
 

