Merge pull request #519 from jonas/spellcheck

Fix typos in the documentation

src/main/scala/com/typesafe/sbt/packager/rpm/Keys.scala

@@ -54,7 +54,7 @@ trait RpmKeys {
   val rpmPosttrans = SettingKey[Option[String]]("rpm-posttrans", "%posttrans scriptlet")
   val rpmPreun = SettingKey[Option[String]]("rpm-preun", "%preun scriptlet")
   val rpmPostun = SettingKey[Option[String]]("rpm-postun", "%postun scriptlet")
-  val rpmBrpJavaRepackJars = SettingKey[Boolean]("brp-java-repack-jars", """Overrides the __os_post_install scriplet
+  val rpmBrpJavaRepackJars = SettingKey[Boolean]("brp-java-repack-jars", """Overrides the __os_post_install scriptlet
       http://swaeku.github.io/blog/2013/08/05/how-to-disable-brp-java-repack-jars-during-rpm-build/ for details""")
 
   // Building

src/sphinx/archetypes/cheatsheet.rst

@@ -88,7 +88,7 @@ generate the ``.bat`` script for windows distributions.
 ``@APP_DEFINES@@`` - will be replaced with a set of variable definitions, like
   ``APP_MAIN_CLASS``, ``APP_MAIN_CLASS``.
 
-You can define addiitonal variable definitions using ``batScriptExtraDefines``.
+You can define additional variable definitions using ``batScriptExtraDefines``.
 
 Bash Script - ``src/templates/bash-template``
 ---------------------------------------------

src/sphinx/archetypes/index.rst

@@ -20,7 +20,7 @@ For example, if you'd like to write Windows Installer XML by hand and manually m
 still leveraging the default configuration for other platforms.
 
 
-Curently, in the nativepackager these archetypes are available:
+Currently, in the nativepackager these archetypes are available:
 
   * Java Command Line Application
   * Java Server Application (Experimental - Debian Only)
@@ -102,7 +102,7 @@ application archetype. The primary differences are:
 Akka Microkernel Application
 ----------------------------
 
-An Akka microkernel application is simlar to a Java Command Line application. Instead of running the classic ``mainClass``, 
+An Akka microkernel application is similar to a Java Command Line application. Instead of running the classic ``mainClass``, 
 an Akka microkernel application instantiates and runs a subclass of 
 `Bootable <https://github.com/akka/akka/blob/master/akka-kernel/src/main/scala/akka/kernel/Main.scala>`_ . A minimal example
 could look like this

src/sphinx/archetypes/java_app/customize.rst

@@ -70,7 +70,7 @@ Here, we define the configuration location for the BASH script too look for the
 
 The configuration file for bash scripts takes arguments for the BASH file on each line, and allows comments which start with the ``#`` character.  Essentially, this provides a set of default arguments when calling the script.
 
-Now that we have ability to configure the JVM, let's add in a more robust method of customizing the applciation.  We'll be using the `Typesafe Config <https://github.com/typesafehub/config>`_ library for this purpose.
+Now that we have ability to configure the JVM, let's add in a more robust method of customizing the application.  We'll be using the `Typesafe Config <https://github.com/typesafehub/config>`_ library for this purpose.
 
 First, let's add it as a dependency in ``build.sbt`` ::
 
@@ -164,13 +164,13 @@ More Complex Scripts
 As you read earlier the ``bashScriptExtraDefines`` sequence allows you to add new lines to the default bash script used to start the application.
 This is useful when you need a setting which isn't mean for the command-line parameter list passed to the java process. The lines added to
 ``bashScriptExtraDefines`` are placed near the end of the script and have access to a number of utility bash functions (e.g. ``addJava``,
-``addApp``, ``addResidual``, ``addDebugger``). You can add lines to this script as we did for the Typesage config file above. For more complex
-scripts you can also inject a seperate file managed in your source tree or resource directory: ::
+``addApp``, ``addResidual``, ``addDebugger``). You can add lines to this script as we did for the Typesafe config file above. For more complex
+scripts you can also inject a separate file managed in your source tree or resource directory: ::
 
     bashScriptExtraDefines ++= IO.readLines(baseDirectory.value / "scripts" / "extra.sh")
 
 This will add the contents of ``/scripts/extra.sh`` in the resource directory to the bash script. Note you should always concatenate lines
-to ``bashScriptExtraDefines`` as other stages in the pipeline may be include linex to the start-script. 
+to ``bashScriptExtraDefines`` as other stages in the pipeline may be include lines to the start-script.
 
 
 
@@ -208,7 +208,7 @@ In order to override full templates, like the default bash script, create a file
     ${{template_declares}}
 
     # Here we make use of two of the injected settings for the bash file:
-    # * app_classpath - represents the full list of JARs for this applciation.
+    # * app_classpath - represents the full list of JARs for this application.
     # * app_mainclass - represents the class with a main method we should call.
     exec java -cp $app_classpath $app_mainclass $@
 
@@ -256,7 +256,7 @@ generate the ``.bat`` script for windows distributions.
 ``@APP_DEFINES@@`` - will be replaced with a set of variable definitions, like
   ``APP_MAIN_CLASS``, ``APP_MAIN_CLASS``.
 
-You can define addiitonal variable definitions using ``batScriptExtraDefines``.
+You can define additional variable definitions using ``batScriptExtraDefines``.
 
 ``src/templates/bash-template``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

src/sphinx/archetypes/java_app/generating-files.rst

@@ -18,7 +18,7 @@ let's create a task which will download a license file.  Add the following to bu
       location
     }
 
-Now, we have a taks that will download the BSD license when run.  Note:  We assume that the license file is
+Now, we have a task that will download the BSD license when run.  Note:  We assume that the license file is
 something you host on your own website and keep up to date separately form the package.
 
 Next, let's wire this license into the package.   The native package, by default, works with **mappings**.

src/sphinx/archetypes/java_app/gettingstarted.rst

@@ -5,7 +5,7 @@ The sbt-native-packager is an sbt plugin.  Please follow the :doc:`Installation
 
 The sbt-native-packager attempts to make building packages for different operating systems easier.  While it provides
 some basic abstractions around packaging, it also allows you to dig down into the nuts and bolts of each platform as
-neeeded to generate the best package possible.   
+needed to generate the best package possible.   
 
 
 Here's the basic architecture of the plugin:

src/sphinx/archetypes/java_app/index.rst

@@ -2,7 +2,7 @@ Java Application Archetype
 ##########################
 
 Application packaging focuses on how your application is launched (via a ``bash`` or ``bat`` script), how dependencies
-are managed and how configuration and other auxillary files are included in the final distributable. The `JavaAppPackaging` archetype
+are managed and how configuration and other auxiliary files are included in the final distributable. The `JavaAppPackaging` archetype
 provides a default application structure and executable scripts to launch your application. 
 
 Additionally there is :doc:`Server Packaging </archetypes/java_server/index>` which provides platform-specific

src/sphinx/archetypes/java_app/my-first-project.rst

@@ -144,7 +144,7 @@ This generates a debian file that will install the following owners and files ::
     root:root                  bin/
     root:root                    example-cli -> ../share/example-cli/bin/example-cli
 
-So, the default packaing takes the "universal" distribution and places it inside a ``/usr/share`` directory, owned by a user for the application.   In addition, there is a a symlink in ``/usr/bin`` to the distributed bin script.  This allows users on the platform to run the ``example-cli`` as a native install.
+So, the default packaging takes the "universal" distribution and places it inside a ``/usr/share`` directory, owned by a user for the application.   In addition, there is a a symlink in ``/usr/bin`` to the distributed bin script.  This allows users on the platform to run the ``example-cli`` as a native install.
 
 We can generate other packages via the following tasks.  Here's a complete list of current options.
 
@@ -156,9 +156,9 @@ We can generate other packages via the following tasks.  Here's a complete list
 * ``universal::packageOsxDmg`` - Generates a DMG file with the same contents as the universal zip/tgz.
 * ``windows:packageBin`` - Generates an MSI
 
-While we only covered the necessary configuration for ``debian``, each package type beyond ``universal`` requires some additonal
+While we only covered the necessary configuration for ``debian``, each package type beyond ``universal`` requires some additional
 configuration relative to that packager.  For example, windows MSIs require UUIDs for all packages which are used to uniquely
-identifiy two packages that may have the same name.
+identify two packages that may have the same name.
 
 Next, let's look at how to :doc:`customize the executable bash/bat scripts<customize>`.
 

src/sphinx/archetypes/java_app/writing-documentation.rst

@@ -43,7 +43,7 @@ Now that the man page is created, we can use a few tasks provided to view it in
     [info] Linux                            NOVEMBER 2011                  EXAMPLE_CLI(1)
 
 
-We can use this task to work on the man pages and ensure they'll look ok.  You can also directly use ``groff`` to view changes in 
+We can use this task to work on the man pages and ensure they'll look OK.  You can also directly use ``groff`` to view changes in 
 your man pages.
 
 In addition to providing the means to view the man page, the native packager will also automatically ``gzip`` man pages for the
@@ -53,6 +53,6 @@ distribution.  The resulting man page is stored in ``/usr/share/man/man1/example
 TODO - A bit more on other documentation methods.
 
 
-That's the end fo the getting started guide for Java Applications!  Feel free to read the guide on 
+That's the end for the getting started guide for Java Applications!  Feel free to read the guide on 
 :doc:`Java Servers </archetypes/java_server/index>`, which offers a few differences in how configuration
 is done for packaging to underlying systems.

src/sphinx/archetypes/java_server/customize.rst

@@ -13,7 +13,7 @@ There are generally two types of configurations:
 
 The server archetype provides you with a special feature to configure your application
 with a single file outside of customizing the ``bash`` or ``bat`` script for applications. 
-As this file is OS dependend, each OS gets section.
+As this file is OS dependent, each OS gets section.
 
 Linux Configuration
 -------------------
@@ -54,7 +54,7 @@ Create ``src/templates/etc-default`` with the following template
     # -no-version-check
     
     # enabling debug and sending -d as app argument
-    # the '--' prevents app-parameter swalloing when
+    # the '--' prevents app-parameter swallowing when
     # using a reserved parameter. See #184
     # -d -- -d
 
@@ -122,7 +122,7 @@ which will add the following resource file to use start/stop instead of initctl
   }
 
 The :doc:`debian </formats/debian>` and :doc:`redhat </formats/rpm>` pages have further information on overriding 
-distribution scpecific actions.
+distribution specific actions.
 
 Override Start Script - ``src/templates/start``
 -----------------------------------------------
@@ -149,7 +149,7 @@ You can use ``${{variable_name}}`` to reference variables when writing your scri
 SystemD Support
 ---------------
 
-There is also experimental systemd support for Fedora release 20 (Heisenbug). You can use the ```Systemd``` server loader:
+There is also experimental SystemD support for Fedora release 20 (Heisenbug). You can use the ```Systemd``` server loader:
 
 .. code-block:: scala
 
@@ -164,12 +164,12 @@ Package Lifecycle Configuration
 Some scripts are covered in the standard application type. Read more on :doc:`Java Application Customization</archetypes/java_app/customize>`.
 For the ``java_server`` package lifecycle scripts are customized to provide the following additional features
 
-* Chowning directories and files correctly (if neccessary)
+* Chowning directories and files correctly (if necessary)
 * Create/Delete users and groups according to your mapping
 * Register application at your init system
 
 For this purpose *sbt-native-packager* ships with some predefined templates. These can be
-overriden with different techniques, depending on the packaging system.
+overridden with different techniques, depending on the packaging system.
 
 Partially Replace Template Functionality
 ----------------------------------------
@@ -225,8 +225,8 @@ Available templates are
     ``postun-rpm``
     ``preun-rpm``
 
-Override Postinst scriplet
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+Override Postinst scriptlet
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 By default the ``post-rpm`` template only starts the service, but doesn't register it.
 

src/sphinx/archetypes/java_server/index.rst

@@ -10,7 +10,7 @@ predefined install and uninstall scripts for various platforms and service manag
 Features
 --------
 
-The `JavaServerAppPackaging` archetype contains all `JavaAppPackaing` feature and the following
+The `JavaServerAppPackaging` archetype contains all `JavaAppPackaging` feature and the following
 
 * install/uninstall services
 * default mappings for server applications

src/sphinx/archetypes/java_server/my-first-project.rst

@@ -105,7 +105,7 @@ the :doc:`linux section </formats/linux>`.
 Debian (.deb)
 =============
 
-A basic ``build.sbt`` for debian requires only the Linuxs settings. You can build your
+A basic ``build.sbt`` for debian requires only the Linux settings. You can build your
 server application with
 
 ::
@@ -125,7 +125,7 @@ both you can add this to your ``build.sbt``
 RPM (.rpm)
 ==========
 
-A basic ``build.sbt`` for rpm requires the Linuxs settings and
+A basic ``build.sbt`` for rpm requires the Linux settings and
 
 .. code-block:: scala
     

src/sphinx/formats/debian.rst

@@ -16,7 +16,7 @@ is activated.
 
   <div class="alert alert-info" role="alert">
     <span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
-    The debian plugin dependens on the linux plugin. For general linux settings read the 
+    The debian plugin depends on the linux plugin. For general linux settings read the 
     <a href="linux.html">Linux Plugin Documentation</a>
   </div>
 
@@ -76,7 +76,7 @@ If you want to use the java based implementation, enable the following plugin.
 ~~~~~~~~~~~~
 
 For this versions debian packaging is automatically activated.
-See the :doc:`Getting Started </gettingstarted>` page for informations
+See the :doc:`Getting Started </gettingstarted>` page for information
 on how to enable sbt native packager.
 
 If you want to enable `jdeb` packaging add the following to your `build.sbt`
@@ -121,7 +121,7 @@ Debian requires the following specific settings:
     These are the packaging scripts themselves used by ``dpkg-deb`` to build your debian.  These
     scripts are used when installing/uninstalling a debian, like prerm, postinstall, etc.  These scripts
     are placed in the ``DEBIAN`` file when building.    Some of these files can be autogenerated,
-    for example when using a package archetype, like server_application.  Howeve, any autogenerated file
+    for example when using a package archetype, like server_application.  However, any autogenerated file
     can be overridden by placing your own files in the ``src/debian/DEBIAN`` directory.
 
   ``changelog in Debian``

src/sphinx/formats/docker.rst

@@ -45,7 +45,7 @@ Required Settings
 ~~~~~
 
 For this versions docker packaging is automatically activated.
-See the :doc:`Getting Started </gettingstarted>` page for informations
+See the :doc:`Getting Started </gettingstarted>` page for information
 on how to enable sbt native packager.
 
 Configuration
@@ -159,8 +159,8 @@ Docker Image Customization
     dockerExposedVolumes := Seq("/opt/docker/logs")
     
     
-In order to work properly with `USER daemon` the exposed volumes first
-created (if not existend) and chowned. 
+In order to work properly with `USER daemon` the exposed volumes are first
+created (if they do not existend) and chowned. 
 
 Install Location
 ~~~~~~~~~~~~~~~~
@@ -214,7 +214,7 @@ the chowning of a exposed volume.
 Add Commands
 ============
 
-Adding commands is as straigtforward as adding anything in a list.
+Adding commands is as straightforward as adding anything in a list.
 
 .. code-block:: scala
 

src/sphinx/formats/jdkpackager.rst

@@ -12,14 +12,14 @@ This plugin's most relevant addition to the core `sbt-native-packager` capabilit
 
   <div class="alert alert-info" role="alert">
     <span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
-    The JDKPackagerPlugin depends on the Universal and JavaAppPackaging plugins. For inherited settings read the <a href="../archetypes/java_app/index.html">Java Applicaiton Plugin Documentation</a>
+    The JDKPackagerPlugin depends on the Universal and JavaAppPackaging plugins. For inherited settings read the <a href="../archetypes/java_app/index.html">Java Application Plugin Documentation</a>
   </div>
 
 
 Requirements
 ------------
 
-The `javapackager` tool comes with JDK 8, and found in the `bin` directory along with `javac` and friends. (An earlier form of the tool was introduced in later forms of JDK 7 as `javafxpackager`.)  If `sbt` is running under the JVM in JDK 8, then the plugin should be able to find the path to `javapcakger`. If `sbt` is running under a different JVM, then the path to the tool will have to be specified via the ``jdkPackagerTool`` setting.
+The `javapackager` tool comes with JDK 8, and found in the `bin` directory along with `javac` and friends. (An earlier form of the tool was introduced in later forms of JDK 7 as `javafxpackager`.)  If `sbt` is running under the JVM in JDK 8, then the plugin should be able to find the path to `javapackager`. If `sbt` is running under a different JVM, then the path to the tool will have to be specified via the ``jdkPackagerTool`` setting.
 
 This plugin must be run on the platform of the target installer. The `javapackager` tool does not provide a means of creating, say, Windows installers on MacOS, etc.
 
@@ -100,7 +100,7 @@ Relevant JVM settings specified in the ``src/universal/conf/jvmopts`` file are p
 Example
 -------
 
-To take it for a test spin, run ``sbt jdkPackager:packageBin`` in the ``test-project-jdkpackager`` directory of the `sbt-native-packager` soruce. Then look in the ``target/jdkpackager/bundles`` directory for the result (specific name depends on platform built).
+To take it for a test spin, run ``sbt jdkPackager:packageBin`` in the ``test-project-jdkpackager`` directory of the `sbt-native-packager` source. Then look in the ``target/jdkpackager/bundles`` directory for the result (specific name depends on platform built).
 
 Here's what the build file looks like:
 

src/sphinx/formats/linux.rst

@@ -12,7 +12,7 @@ The native packager plugin is designed so that linux packages look similar, but
 
   <div class="alert alert-info" role="alert">
     <span class="glyphicon glyphicon-info-sign" aria-hidden="true"></span>
-    The linux plugin dependens on the universal plugin. For universal settings read the 
+    The linux plugin depends on the universal plugin. For universal settings read the 
     <a href="universal.html">Universal Plugin Documentation</a>
   </div>
 
@@ -72,11 +72,11 @@ Enable the debian plugin to activate the native package implementation.
 ~~~~~~~~~~~~
 
 For this versions linux packaging is automatically activated.
-See the :doc:`Getting Started </gettingstarted>` page for informations
+See the :doc:`Getting Started </gettingstarted>` page for information
 on how to enable sbt native packager.
 
 In order to use the utility functions you need to import them with
-(if you haven't alreay imported this)
+(if you haven't already imported this)
 
 .. code-block:: scala
 
@@ -236,7 +236,7 @@ The basic construct for adding looks like this
     linuxPackageMappings += packageMapping( (theFile, "/absolute/path/somefile.txt") ) withPerms("644") asDocs()
     
 If you want to filter or alter things. The example has a lot of things you can _possibly_ do. Just pick
-what you need. After this section there are smaller examples, showing how you can implemenet certain functions.
+what you need. After this section there are smaller examples, showing how you can implement certain functions.
 
 .. code-block:: scala
 
@@ -291,7 +291,7 @@ To add an arbitrary file in your build path
       packageMapping( (file, "/absolute/path/somefile.txt") )
     }
 
-``linuxPackageMappings`` can be scoped to ``Rpm` or ``Debian`` if you want to add mappings only for a single packacking type.
+``linuxPackageMappings`` can be scoped to ``Rpm` or ``Debian`` if you want to add mappings only for a single packaging type.
 
 .. code-block:: scala