use consistent spelling for customize throughout docs and codebase

- some minor other spelling improvements along the way

README.md

@@ -38,7 +38,7 @@ To create a full installation (includes docs)…
 
 ### Working with subprojects
 
-The Gradle build uses Gradle's ability to customise the logical structure of a multiproject build. All of the build's subprojects are in the `subprojects/` directory and are mapped to top level children in [settings.gradle](https://github.com/gradle/gradle/blob/master/settings.gradle).
+The Gradle build uses Gradle's ability to customize the logical structure of a multiproject build. All of the build's subprojects are in the `subprojects/` directory and are mapped to top level children in [settings.gradle](https://github.com/gradle/gradle/blob/master/settings.gradle).
 
 This means that to build just the `core` subproject (that lives in `subprojects/core`) you would run:
 

design-docs/building-and-packaging-applications-and-libraries.md

@@ -209,7 +209,7 @@ To generate multiple distributions:
 
 Running `gradle distZip customDistZip` will create the distribution ZIP files.
 
-## Allow customisation of the `distribution` plugin
+## Allow customization of the `distribution` plugin
 
 Allow the distributions defined by the `distribution` to be configured and remove the configuration options from the `java-library-distribution` plugin.
 

design-docs/continuous-delivery-for-c-plus-plus.md

@@ -174,7 +174,7 @@ Running `gradle customStaticLibrary customSharedLibrary` will build the static a
 - For a build that uses the `cpp` plugin and defines multiple libraries, each library can be built as both a static and shared library binary.
 - Can link a static library into an executable and install and run the resulting executable.
 
-## Story: Allow customisation of binaries before and after linking
+## Story: Allow customization of binaries before and after linking
 
 This story introduces a lifecycle task for each binary, to allow tasks to be wired into the task graph for a given binary. These tasks will be able to modify the object files or binary files before they are consumed.
 
@@ -206,13 +206,13 @@ This story introduces a lifecycle task for each binary, to allow tasks to be wir
 
 - Some convenience to wire this in?
 
-## Story: Allow customisation of binary compilation and linking
+## Story: Allow customization of binary compilation and linking
 
 This story allows some configuration of the settings used to compile and link a given binary.
 
 Some initial support for settings that will be shared by all binaries of a component will also be added.
 
-Later stories will add more flexible and convenient support for customisation of the settings for a binary.
+Later stories will add more flexible and convenient support for customization of the settings for a binary.
 
 - Add the following mutable properties to `NativeBinary`:
     - `outputFile`
@@ -262,7 +262,7 @@ Later stories will add more flexible and convenient support for customisation of
 - `NativeComponent.binaries` collides with `project.binaries`, for example, when defining binary libs.
 - `NativeComponent.binaries.all { }` is awkward for linker settings, as these aren't available for a shared lib binary.
 - Add back some conveniences for compiler and linker args for all binaries once delayed configuration is implemented.
-- Allow customisation of the source sets for a binary.
+- Allow customization of the source sets for a binary.
 - Strongly type the compiler and linker args as `String`.
 - Need to run `ranlib` over static libraries.
 
@@ -670,11 +670,11 @@ Each variant has a platform associated with it.
 
     binaries.all {
         if (binary.platform == platforms.x86_optimised) {
-            // Customise arguments for "x86_optimised" variants
+            // Customize arguments for "x86_optimised" variants
         }
 
         if (binary.platform.architecture.name == "x86") {
-            // Customise arguments for all "x86_standard" and "x86_optimised" variants
+            // Customize arguments for all "x86_standard" and "x86_optimised" variants
         }
     }
 
@@ -998,7 +998,7 @@ TBD
 
 * Allow the visual studio project file to be generated.
 * Merge with existing project file, as for IDEA and Eclipse.
-* Add hooks for customising the generated XML.
+* Add hooks for customizing the generated XML.
 
 # Milestone 4
 

design-docs/done/publication-model.md

@@ -1,4 +1,4 @@
-## Customising Ivy descriptor XML (DONE)
+## Customizing Ivy descriptor XML (DONE)
 
 This initial step will provide some capability to modify the generated `ivy.xml` files before publication. It will introduce a new set of tasks for publishing
 to repositories.
@@ -39,7 +39,7 @@ To publish an Ivy module:
 
 Running `gradle publish` will build the artifacts and upload to the specified repository.
 
-To customise the `ivy.xml`:
+To customize the `ivy.xml`:
 
     apply plugin: 'ivy-publish'
 
@@ -74,7 +74,7 @@ To publish to multiple repositories:
 
 Running `gradle publish` will publish the module to both repositories.
 
-The `ivy-publish` plugin is intended to move Ivy concepts out of the core Gradle DSL, but still allow them to be available for customisation for those
+The `ivy-publish` plugin is intended to move Ivy concepts out of the core Gradle DSL, but still allow them to be available for customization for those
 projects that use Ivy. It also allows us to introduce some breaking changes, in an opt-in way.
 
 Note: there are some breaking changes here when you apply the `ivy-publish` plugin:
@@ -100,7 +100,7 @@ at this point to start pulling descriptor generation up, so that it can eventual
 * Decent error message when the `withXml` action fails.
 * Descriptor contains non-ascii characters.
 
-## Customising Maven descriptor XML (DONE)
+## Customizing Maven descriptor XML (DONE)
 
 This step will provide some capability to modify the generated `pom.xml` files before publication. It will introduce the ability to use the new
 publication tasks to publish Maven modules.
@@ -137,7 +137,7 @@ To publish a Maven module:
 Running `gradle publish` will build the artifacts and upload to the specified repository. Running `gradle publishMavenLocal` will build the artifacts and
 copy them into the local Maven repository.
 
-To customise the `pom.xml`:
+To customize the `pom.xml`:
 
     apply plugin: 'maven-publish'
 
@@ -316,9 +316,9 @@ Note: there is a breaking change in this story, as nothing is published by defau
 - Add a cross version test that verifies that a web application published to a Maven repository by the current Gradle version can be resolved by a previous Gradle version.
 - Copy existing Maven publication tests for web applications and rework to use `maven-publish` plugin.
 
-## Allow outgoing artifacts to be customised for Maven publications
+## Allow outgoing artifacts to be customized for Maven publications
 
-This step allows the outgoing artifacts to be customised for a Maven publication.
+This step allows the outgoing artifacts to be customized for a Maven publication.
 
 1. Add a `MavenArtifact` interface with the following attributes:
     * `extension`
@@ -329,7 +329,7 @@ This step allows the outgoing artifacts to be customised for a Maven publication
 4. When publishing, validate that (extension, classifier) is unique for each artifact.
 5. When publishing, validate that the artifact file exists and is a file.
 
-To customise a Maven publication:
+To customize a Maven publication:
 
     apply plugin: 'maven-publish'
 
@@ -425,7 +425,7 @@ Note: there is a breaking change in this story.
 * Cross-version test that verifies a Java project published by the current version of Gradle can be consumed by a previous version of Gradle,
   and vice versa.
 
-## Allow outgoing artifacts to be customised for Ivy publications (DONE)
+## Allow outgoing artifacts to be customized for Ivy publications (DONE)
 
 1. Add an `IvyArtifact` interface with the following attributes:
     * `name`
@@ -440,7 +440,7 @@ Note: there is a breaking change in this story.
 5. When publishing or generating the descriptor, validate that the (name, type, extension, classifier) attributes are unique for each artifact.
 6. When publishing, validate that the artifact file exists and is a file.
 
-To customise an Ivy publication:
+To customize an Ivy publication:
 
     apply plugin: 'ivy-publish'
 

design-docs/enterprise-environment-test-coverage.md

@@ -17,7 +17,7 @@ In each use case, the 'standard enterprise environment' includes:
 2. Developer installs Gradle and executes build that resolves dependency in corporate repository.
 3. Developer installs Gradle and executes build that publishes module to standard corporate repository.
 4. Developer executes wrapper build where wrapper downloads Gradle version from services.gradle.org in standard enterprise environment.
-5. Developer executes wrapper build where wrapper downloads customised Gradle version from corporate repository in standard enterprise environment.
+5. Developer executes wrapper build where wrapper downloads customized Gradle version from corporate repository in standard enterprise environment.
 6. Developer installs Gradle and executes build that applies external script file that is downloaded from the internet in standard enterprise environment.
 
 # Implementation plan

design-docs/publication-model.md

@@ -10,7 +10,7 @@ Note: this spec is very much a work in progress.
 
 AKA 'Ivy deliver'. In this instance, dependency declarations in the generated descriptors should use the resolved versions that were used to build the artifacts.
 
-## I want to customise the Ivy or Maven meta-data for a publication
+## I want to customize the Ivy or Maven meta-data for a publication
 
 * Use a (groupId, artifactId, version) identifier that is different to defaults.
 * Add some custom Ivy attributes for the module or a configuration or an artifact.
@@ -23,7 +23,7 @@ AKA 'Ivy deliver'. In this instance, dependency declarations in the generated de
 * I want to publish test fixtures as a separate module.
 * I produce Groovy 1.8 and Groovy 2.0 variants that I want to publish as separate modules.
 
-## I want to customise a publication based on its destination
+## I want to customize a publication based on its destination
 
 * I want to map the 32-bit and 64-bit variants of a native library to `mylib-x86-1.2.dll` and `mylib-amd64-1.2.dll` when publishing to an Ivy repository,
   and to `mylib-1.2-x86.dll` and `mylib-1.2-amd64.dll` when publishing to a Maven repository.
@@ -70,9 +70,9 @@ Note: for the following discussion, all changes are `@Incubating` unless specifi
 
 See [completed stories](done/publication-model.md)
 
-## Customising the Maven and Ivy publication identifier
+## Customizing the Maven and Ivy publication identifier
 
-This step will allow some basic customisation of the meta data model for each publication:
+This step will allow some basic customization of the meta data model for each publication:
 
 1. Add `groupId`, `artifactId`, `version` properties to `MavenPublication`. Add `packaging` property to `MavenPom`.
 2. Change `pom.xml` generation to use these properties.
@@ -91,7 +91,7 @@ This step will allow some basic customisation of the meta data model for each pu
 
 A side-effect of this change is that it will be possible to create and publish multiple publications from a single build.
 
-To customise the `pom.xml`:
+To customize the `pom.xml`:
 
     apply plugin: 'maven-publish'
 
@@ -108,10 +108,10 @@ To customise the `pom.xml`:
         }
     }
 
-Running `gradle publish` will publish to the remote repository, with the customisations. Running `gradle publishLocalMaven` will publish to the local
-Maven repository, with the same customisations.
+Running `gradle publish` will publish to the remote repository, with the customizations. Running `gradle publishLocalMaven` will publish to the local
+Maven repository, with the same customizations.
 
-To customise the `ivy.xml`:
+To customize the `ivy.xml`:
 
     apply plugin: 'ivy-publish'
 
@@ -130,7 +130,7 @@ To customise the `ivy.xml`:
 ### Integration test cases
 
 * A build with project-A depends on project-B.
-    1. Customise the Ivy module identifier and Maven coordinates of project-B.
+    1. Customize the Ivy module identifier and Maven coordinates of project-B.
     2. Publish both projects to an Ivy repository.
     3. Assert that another build can resolve project-A from this Ivy repository.
     4. Publish both projects to a Maven repository.
@@ -228,7 +228,7 @@ This story will address this issue, by ensuring that failure to publish is detec
 * Publish an Ivy publication to an HTTP repository that returns a 500. Assert that failure is reported.
 * Similar tests for Maven publications.
 
-## Allow outgoing dependency declarations to be customised
+## Allow outgoing dependency declarations to be customized
 
 This step decouples the incoming and outgoing dependency declarations, to allow each publication to include a different set of dependencies:
 
@@ -360,7 +360,7 @@ And:
 
 TBD
 
-## Customise the output file for the generated descriptor
+## Customize the output file for the generated descriptor
 
 TBD
 
@@ -445,9 +445,9 @@ These would be mixed in to various steps above (TBD), rather than as one change
 8. Deprecate and later remove `Configuration` and related types.
 9. Deprecate and later remove support for resolving or publishing using an Ivy DependencyResolver implementation.
 
-## Add further meta-data customisations
+## Add further meta-data customizations
 
-At any point above, and as required, more meta-data for a publication can be made available for customisation. In particular:
+At any point above, and as required, more meta-data for a publication can be made available for customization. In particular:
 
 1. Add `name`, `description`, `url`, `licenses`, `organization`, `scm`, `issueManagement` and `mailingLists` to `MavenPublication`
 2. Add extended attributes to `IvyModuleDescriptor`, `IvyConfiguration` and `IvyArtifact`.

subprojects/docs/README.md

@@ -40,7 +40,7 @@ You can run the `editReleaseNotes` task to open the raw markdown notes in whatev
 
 ## Userguide
 
-The source for the userguide lives @ `src/docs/userguide`. The userguide is authored using [docbook](http://www.docbook.org/) and uses [docbook stylesheets](http://docbook.sourceforge.net/) with some customisations in `src/stylesheets` to generate HTML. It uses [Flying Saucer](https://xhtmlrenderer.dev.java.net/) + [iText](http://www.lowagie.com/iText/) to generate the PDF from the HTML.
+The source for the userguide lives @ `src/docs/userguide`. The userguide is authored using [docbook](http://www.docbook.org/) and uses [docbook stylesheets](http://docbook.sourceforge.net/) with some customizations in `src/stylesheets` to generate HTML. It uses [Flying Saucer](https://xhtmlrenderer.dev.java.net/) + [iText](http://www.lowagie.com/iText/) to generate the PDF from the HTML.
 
 When adding new content, it's generally best to find an example of the kind of content that you want to add somewhere else in the userguide and copy it.
 

subprojects/docs/src/docs/stylesheets/dslHtml.xsl

@@ -34,14 +34,14 @@
 
     <xsl:template name="formal.object.heading"></xsl:template>
 
-    <!-- customise the stylesheets to add to the <head> element -->
+    <!-- customize the stylesheets to add to the <head> element -->
     <xsl:template name="output.html.stylesheets">
         <link href="base.css" rel="stylesheet" type="text/css"/>
         <link href="docs.css" rel="stylesheet" type="text/css"/>
         <link href="dsl.css" rel="stylesheet" type="text/css"/>
     </xsl:template>
 
-    <!-- Customise the page titles -->
+    <!-- customize the page titles -->
     <xsl:template match="book" mode="object.title.markup.textonly">
         <xsl:value-of select="bookinfo/titleabbrev"/>
         <xsl:text> Version </xsl:text>
@@ -54,7 +54,7 @@
         <xsl:apply-templates select="/book" mode="object.title.markup.textonly"/>
     </xsl:template>
 
-    <!-- customise the layout of the html page -->
+    <!-- customize the layout of the html page -->
     <xsl:template name="chunk-element-content">
         <xsl:param name="prev"/>
         <xsl:param name="next"/>
@@ -149,7 +149,7 @@
     </xsl:template>
 
     <!--
-      - Customised header for property and method detail sections
+      - Customized header for property and method detail sections
       -->
 
     <xsl:template match="section[@role='detail']/title" mode="titlepage.mode">
@@ -170,7 +170,7 @@
     </xsl:template>
 
     <!--
-      - Customised <segmentedlist> formats
+      - Customized <segmentedlist> formats
       -->
     <xsl:template match="segmentedlist">
         <div>

subprojects/docs/src/docs/stylesheets/userGuideHtmlCommon.xsl

@@ -88,7 +88,7 @@
 
     <!-- BOOK TITLEPAGE -->
 
-    <!-- Customise the contents of the book titlepage -->
+    <!-- Customize the contents of the book titlepage -->
     <xsl:template name="book.titlepage">
         <div class="titlepage">
             <div class="title">

subprojects/docs/src/docs/userguide/artifactMngmt.xml

@@ -69,7 +69,7 @@
             </sample>
             <para>Gradle will figure out the properties of the artifact based on the name of the file. You can customize these properties:</para>
             <sample id="fileArtifact" dir="userguide/artifacts/uploading" title="Customizing an artifact">
-                <sourcefile file="build.gradle" snippet="customised-file-artifact"/>
+                <sourcefile file="build.gradle" snippet="customized-file-artifact"/>
             </sample>
             <para>There is a map-based syntax for defining an artifact using a file. The map must include a <literal>file</literal> entry that
                 defines the file. The map may include other artifact properties:

subprojects/docs/src/docs/userguide/depMngmt.xml

@@ -19,7 +19,7 @@
         <title>Introduction</title>
         <para>Dependency management is a critical feature of every build, and Gradle has placed an emphasis on offering first-class dependency management that is both easy-to-understand and
             compatible with a wide variety of approaches. If you are familiar with the approach used by either Maven or Ivy you will be delighted to learn that Gradle is fully compatible with both
-            approaches in addition to being flexible enough to support fully-customised approaches.
+            approaches in addition to being flexible enough to support fully-customized approaches.
         </para>
 
         <para>Here are the major highlights of Gradle's support for dependency management:</para>
@@ -38,7 +38,7 @@
                 </para>
             </listitem>
             <listitem>
-                <para><emphasis>A fully customisable approach to Dependency Resolution</emphasis>: Gradle provides you with the ability to customize resolution rules making dependency substitution
+                <para><emphasis>A fully customizable approach to Dependency Resolution</emphasis>: Gradle provides you with the ability to customize resolution rules making dependency substitution
                     easy.
                 </para>
             </listitem>
@@ -87,7 +87,7 @@
             <para>Both tools rely on descriptor XML files, which contain information about the dependencies of a particular jar. Both also use repositories where the actual jars are placed together
                 with their descriptor files, and both offer resolution for conflicting jar versions in one form or the other. Both have emerged as standards for solving dependency conflicts, and while
                 Gradle originally used Ivy under the hood for its dependency management. Gradle has replaced this direct dependency on Ivy with a native Gradle dependency resolution engine which
-                supports a range of approached to dependency resolution including both POM and Ivy descriptor files.
+                supports a range of approaches to dependency resolution including both POM and Ivy descriptor files.
             </para>
         </section>
     </section>

subprojects/docs/src/docs/userguide/eclipsePlugin.xml

@@ -271,7 +271,7 @@
     <section>
         <title>Customizing the generated files</title>
         <para>
-            The Eclipse plugin allows you to customise the generated metadata files. The plugin provides a DSL for configuring model objects
+            The Eclipse plugin allows you to customize the generated metadata files. The plugin provides a DSL for configuring model objects
             that model the Eclipse view of the project. These model objects are then merged with the existing Eclipse XML metadata to ultimately
             generate new metadata. The model objects provide lower level hooks for working with domain objects representing the file content 
             before and after merging with the model configuration. They also provide a very low level hook for working directly with the raw