diff --git a/src/sphinx/DetailedTopics/debian.rst b/src/sphinx/DetailedTopics/debian.rst
deleted file mode 100644
index be4339650..000000000
--- a/src/sphinx/DetailedTopics/debian.rst
+++ /dev/null
@@ -1,188 +0,0 @@
-Debian
-======
-The debian package specification is very robust and powerful.  If you wish to do any advanced features, it's best to understand how
-the underlying packaging system works.  http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/ is an excellent tutorial.
-
-
-
-Getting Started
----------------
-By default, the debian packaging settings will take all files under ``src/debian/DEBIAN`` and map them into the debian control directory.
-Make sure you have to following tools installed on your machine in order to build debian packages natively:
-
-* dpkg-deb
-* dpkg-sig
-* dpkg-genchanges
-* lintian
-* fakeroot
-
-If you are on windows you can try to use the jdeb packaging described below.
-
-Settings
---------
-
-Debian requires the following specific settings:
-
-  ``name in Debian``
-    The name of the package for debian (if different from general linux name).
-
-  ``version in Debian``
-    The debian-friendly version of the package.   Should be of the form ``x.y.z-build-aa``.
-
-  ``debianPackageDependencies in Debian``
-    The list of debian packages that this package depends on.
-
-  ``debianPackageRecommends in Debian``
-    The list of debian packages that are recommended to be installed with this package.
-
-  ``linuxPackageMappings in Debian``
-    Debian requires a ``/usr/share/doc/{package name}/changelog.gz`` file that describes
-    the version changes in this package. These should be appended to the base linux versions.
-
-  ``debianMaintainerScripts``
-    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
-    can be overridden by placing your own files in the ``src/debian/DEBIAN`` directory.
-
-  ``changelog in Debian``
-    This is the changelog used by ``dpkg-genchanges`` to create the .changes file. This will allow you to
-    upload the debian package to a mirror.
-
-
-Tasks
------
-
-The Debian support grants the following commands:
-
-  ``debian:package-bin``
-    Generates the ``.deb`` package for this project.
-
-  ``debian:lintian``
-    Generates the ``.deb`` file and runs the ``lintian`` command to look for issues in the package.  Useful for debugging.
-
-  ``debian:gen-changes``
-    Generates the ``.changes``, and therefore the ``.deb`` package for this project.
-    
-
-Examples
---------
-
-Plain Debian Packaging
-~~~~~~~~~~~~~~~~~~~~~~
-
-For a basic debian packaging your ``build.sbt`` must contain the following settings
-
-.. code-block:: scala
-
-    import NativePackagerKeys._
-
-    name := "Debian Example"
-
-    version := "1.0"
-
-    packageArchetype.java_application
-
-    maintainer := "Max Smith <max.smith@yourcompany.io>"
-
-    packageSummary := "Hello World Debian Package"
-
-    packageDescription := """A fun package description of our software,
-      with multiple lines."""
-      
-When you run ``sbt debian:packageBin`` you will find a debian package in your ``target`` folder.
-
-Multi OS Packaging with Debian
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you package for multiple operating systems you may have to be a bit more explicit in your ``build.sbt``.
-For example
-
-.. code-block:: scala
-
-    import NativePackagerKeys._
-
-    name := "Example Package"
-
-    version := "1.0"
-
-    packageArchetype.java_application
-
-    maintainer in Debian := "Max Smith <max.smith@yourcompany.io>"
-    
-    maintainer in Windows := "Jane Smith <jane.smith@yourcompany.io>"
-
-    packageSummary in Debian := "Hello World Debian Package"
-    
-    packageSummary in Windows := "Hello World Windows Package"
-
-    packageDescription := """A fun package description of our software,
-      with multiple lines."""
-      
-As you see, we duplicated the ``maintainer`` and ``packageSummary`` setting, but defined it for
-different configuration scopes. 
-
-Customizing Debian Packaging
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A Debian package provides metadata, which includes **dependencies** and **recommendations**.
-A basic example to depend on java and recommend a git installation.
-
-.. code-block:: scala
-
-    debianPackageDependencies in Debian ++= Seq("java2-runtime", "bash (>= 2.05a-11)")
-
-    debianPackageRecommends in Debian += "git"
-    
-To hook into the debian package lifecycle (https://wiki.debian.org/MaintainerScripts) you
-can add ``preinst`` , ``postinst`` , ``prerm`` and/or ``postrm`` scripts. Just place them into
-``src/debian/DEBIAN``.
-
-If you use the ``packageArchetype.java_server`` there are predefined ``postinst`` and
-``preinst`` files, which start/stop the application on install/remove calls. Existing
-maintainer scripts will be extended not overridden.
-
-Your control scripts are in a different castle.. directory? No problem.
-
-.. code-block:: scala
-
-    debianControlScriptsDirectory <<= (sourceDirectory) apply (_ / "deb" / "control")
-
-Customizing Debian Server Archetype
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The debian packaging supports the ``packageArchetype.java_server``, which generates
-autostart scripts and some default links for logging and configuration. 
-
-The default configuration looks like this (that means you don't have to add anything!)
-
-.. code-block:: scala
-
-    import com.typesafe.sbt.packager.archetypes.ServerLoader.{Upstart, SystemV}
-
-    serverLoading := Upstart
-
-The default configuration will create a default system user and group for ownerships of the
-installed files. This user will also be used to execute the daemon service so it does
-not run as the **root** user.
-
-This default can be overridden using the ``appUser`` and ``appGroup`` keys, change
-these values as you need. The user or group you define in the appropriate keys will be
-created within in the ``postinst`` script and removed with ``apt-get purge`` through the
-``postrm`` script.
-
-For more information look at the :ref:`Archetypes` page.
-
-Use JDeb for Debian Packaging
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If don't run a linux or mac system with ``dpkg`` installed, you can configure the
-debian packaging be done by `jdeb`_ . To enable this just set another packaging
-implementation in your ``build.sbt``
-
-.. code-block:: scala
-
-    packageBin in Debian <<= debianJDebPackaging in Debian
-    
-.. _jdeb: https://github.com/tcurdt/jdeb
diff --git a/src/sphinx/DetailedTopics/docker.rst b/src/sphinx/DetailedTopics/docker.rst
deleted file mode 100644
index 3177305e5..000000000
--- a/src/sphinx/DetailedTopics/docker.rst
+++ /dev/null
@@ -1,93 +0,0 @@
-Docker
-======
-
-Docker images describe how to set up a container for running an application, including what files are present, and what program to run.
-
-  https://docs.docker.com/introduction/understanding-docker/ provides an introduction to Docker.
-  https://docs.docker.com/reference/builder/ describes the Dockerfile; a file which describes how to set up the image.
-
-  sbt-native-packager focuses on creating a Docker image which can "just run" the application built by SBT.
-
-Settings
---------
-
-Docker images require the following setting:
-
-.. code-block:: scala
-
-    import NativePackagerKeys._
-    maintainer in Docker := "John Smith <john.smith@example.com>"
-
-It may require these settings:
-
-.. code-block:: scala
-
-    packageName in Docker := packageName.value,
-    version in Docker := version.value,
-    dockerBaseImage := "dockerfile/java",
-    dockerRepository := Some("dockeruser"),
-    dockerExposedPorts in Docker := Seq(9000, 9443),
-    dockerExposedVolumes in Docker := Seq("/opt/docker/logs")
-
-Informational Settings
-~~~~~~~~~~~~~~~~~~~~~~
-
-    
-  ``packageName in Docker``
-    The name of the package for Docker (if different from general name).
-    This will only affect the image name.
-
-  ``version in Docker``
-    The version of the package for Docker (if different from general version).  Often takes the form ``x.y.z``.
-
-  ``maintainer in Docker``
-    The maintainer of the package, required by the Dockerfile format.
-
-Environment Settings
-~~~~~~~~~~~~~~~~~~~~
-
-  ``dockerBaseImage``
-    The image to use as a base for running the application. It should include binaries on the path for ``chown``, ``mkdir``, have a discoverable ``java`` binary, and include the user configured by ``daemonUser`` (``daemon``, by default).
-
-  ``daemonUser in Docker``
-    The user to use when executing the application. Files below the install path also have their ownership set to this user.
-
-  ``dockerExposedPorts in Docker``
-    A list of ports to expose from the Docker image.
-
-  ``dockerExposedVolumes in Docker``
-    A list of data volumes to make available in the Docker image.
-
-  ``dockerEntrypoint in Docker``
-    Overrides the default entrypoint for docker-specific service discovery tasks before running the application.
-    Defaults to the bash executable script, available at ``bin/<script name>`` in the current ``WORKDIR`` of ``/opt/docker``.
-
-Publishing Settings
-~~~~~~~~~~~~~~~~~~~
-
-  ``dockerRepository``
-    The repository to which the image is pushed when the ``docker:publish`` task is run. This should be of the form ``[username]`` (assumes use of the ``index.docker.io`` repository) or ``[repository.host]/[username]``.
-
-  ``dockerUpdateLatest``
-    The flag to automatic update the latest tag when the ``docker:publish`` task is run. Default value is ``FALSE``.
-
-Tasks
------
-The Docker support provides the following commands:
-
-  ``docker:stage``
-    Generates a directory with the Dockerfile and environment prepared for creating a Docker image.
-
-  ``docker:publishLocal``
-    Builds an image using the local Docker server.
-
-  ``docker:publish``
-    Builds an image using the local Docker server, and pushes it to the configured remote repository.
-
-
-Install Location
-----------------
-The path to which the application is written can be changed with the setting
-
-  ``defaultLinuxInstallLocation in Docker``
-    The files from ``mappings in Docker`` are extracted underneath this directory.
diff --git a/src/sphinx/DetailedTopics/index.rst b/src/sphinx/DetailedTopics/index.rst
deleted file mode 100644
index 5dffb878e..000000000
--- a/src/sphinx/DetailedTopics/index.rst
+++ /dev/null
@@ -1,18 +0,0 @@
-Advanced Topics
-###############
-
-
-
-.. toctree::
-   :maxdepth: 2
-   
-   archetypes.rst
-   universal.rst   
-   linux.rst
-   redhat.rst
-   debian.rst
-   windows.rst
-   docker.rst
-   paths.rst
-   custom.rst
-   play.rst
diff --git a/src/sphinx/DetailedTopics/linux.rst b/src/sphinx/DetailedTopics/linux.rst
deleted file mode 100644
index 640d2927a..000000000
--- a/src/sphinx/DetailedTopics/linux.rst
+++ /dev/null
@@ -1,291 +0,0 @@
-.. _Linux:
-
-Writing Linux Packages
-======================
-
-The native packager plugin is designed so that linux packages look similar, but can contain distribution specific information.  
-
-Settings
---------
-The required fields for any linux distribution are:
-
-  ``name in Linux``
-    The name given the package for installation.
-
-  ``maintainer``
-    The name of the maintainer of the package (important for ownership and signing).
-
-  ``packageSummary``
-    A one-sentence short summary of what the package does.
-
-  ``packageDescription``
-    A longer description of what the package does and what it includes.
-
-  ``linuxPackageMappings``
-    A list of files and their desired installation locations for the package, as well as other metainformation.
-
-
-Package Mappings
-----------------
-
-Most of the work in generating a linux package is constructing package mappings.  These 'map' a file to a location on disk where it should
-reside as well as information about that file. Package mappings allow the specification of file ownership, permissions and whether or not
-the file can be considered "configuration".  
-
-  Note that while the ``sbt-native-packager`` plugin allows you to specify all of this information, not all platforms will make use of the
-  information.  It's best to be specific about how you want files handled and run tests on each platform you wish to deploy to.
-
-A package mapping takes this general form
-
-.. code-block:: scala
-
-    (packageMapping(
-        file -> "/usr/share/man/man1/sbt.1.gz"
-      ) withPerms "0644" gzipped) asDocs()
-      
-
-
-Let's look at each of the methods supported in the packageMapping 'library'.
-
-
-  ``packageMapping(mappings: (File, String)*)``
-    This method takes a variable number of ``File -> String`` pairs.  The ``File`` should be a locally available file that can be bundled, 
-    and the ``String`` is the installation location on disk for that file.  This returns a new ``PackageMapping`` that supports the remaining methods.
-
-  ``withPerms(mask: String)``
-    This function adjusts the installation permissions of the associated files.  The flags passed should be of the form of a mask, e.g. ``0755``.  
-
-  ``gzipped``
-    This ensures that the files are written in compressed format to the destination.  This is a convenience for distributions that want files zipped.
-
-  ``asDocs``
-    This denotes that the mapped files are documentation files.  *Note: I believe these are only used for ``RPM``s.*
-
-  ``withConfig(value:String="true")``
-    This denotes whether or not a ``%config`` attribute is attached to the given files in the generated rpm SPEC.  Any value other than ``"true"`` will be
-    placed inside the ``%config()` definition, for example ``withConfig("noreplace")`` results in ``%config(noreplace)`` attribute in the rpm spec.
-
-  ``withUser(user:String)``
-    This denotes which user should be the owner of the given files in the resulting package.
-
-  ``withGroup(group:String)``
-    This denotes which group should be the owner of the given files in the resulting package.
-    
-
-
-The LinuxPackageMapping Models
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-All classes are located in the ``com.typesafe.sbt.packager.linux`` package. So if you want to create
-instances yourself you have to add ``import com.typesafe.sbt.packager.linux._`` to your build file.
-
-A ``LinuxPackageMapping`` contains the following fields:
-
-  ``mappings: Traversable[(File, String)]``
-    A list of mappings aggregated by this LinuxPackageMapping
-    
-  ``fileData: LinuxFileMetaData``
-    Permissions for all the defined mappings. Default to "root:root 755"
-    
-  ``zipped: Boolean``
-    Are the mappings zipped. Default to false
-    
-All mappings are stored in the task ``linuxPackageMappings`` which returns a ``Seq[LinuxPackageMapping]``. To display the contents
-open the sbt console and call
-
-.. code-block:: bash
-
-    show linuxPackageMappings
-    
-
-The ``LinuxFileMetaData`` has the following fields
-
-  ``user: String``
-    The user owning all the mappings. Default "root"
-    
-  ``group: String``
-    The group owning all the mappings. Default "root"
-    
-  ``permissions: String``
-    Access permissions for all the mappings. Default "755"
-    
-  ``config: String``
-    Are the mappings config files. Default "false"
-    
-  ``docs: Boolean``
-    Are the mappings docs. Default to false
-    
-Last but not least there are the ``linuxPackageSymlinks``, which encapsulate symlinks on your
-destination system. A ``LinuxSymlink`` contains only  two fields
-
-  ``link: String``
-    The actual link that points to ``destination``
-    
-  ``destination: String``
-    The link destination
-    
-You can see all currently configured symlinks with this simple command. 
-``linuxPackageSymlinks`` is just a ``Seq[LinuxSymlink]``
-    
-.. code-block:: bash
-
-    show linuxPackageSymlinks
-    
-    
-Modifying Mappings in General
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Adding, filtering and altering mappings are always simple methods on a sequence: ``Seq[LinuxPackageMapping]``.
-The basic construct for adding looks like this
-
-.. code-block:: scala
-
-    // simple
-    linuxPackageMappings += packageMapping( (theFile, "/absolute/path/somefile.txt") )
-    
-    // specialized
-    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.
-
-.. code-block:: scala
-
-    // sbt 0.13.0 syntax
-    linuxPackageMappings := {
-        // mappings: Seq[LinuxPackageMapping]
-        val mappings = linuxPackageMappings.value
-        // this process will must return another Seq[LinuxPackageMapping]
-        mappings map {  linuxPackage => 
-            // basic scala collections operations. Seq[(java.io.File, String)]
-            val filtered = linuxPackage.mappings map { 
-                case (file, name) => file -> name // altering stuff here
-            } filter { 
-                case (file, name) => true // remove stuff from mappings
-            }
-            // case class copy method. Specify only what you need
-            val fileData = linuxPackage.fileData.copy(
-                user = "new user",
-                group = "another group",
-                permissions = "444",
-                config = "false",
-                docs = false
-            )
-            // case class copy method. Specify only what you need.
-            // returns a fresh LinuxPackageMapping
-            linuxPackage.copy(
-                mappings = filtered,
-                fileData = fileData
-            )
-        } filter { 
-            linuxPackage => linuxPackage.mappings.nonEmpty // remove stuff. Here all empty linuxPackageMappings
-        }    
-    }
-    
-    // sbt 0.12.x syntax
-    linuxPackageMappings <<= linuxPackageMappings map { mappings => 
-        /* stuff. see above */ 
-        mappings 
-    }
-
-The ordering in which you apply the tasks is important. 
-
-Add Mappings
-~~~~~~~~~~~~
-
-To add an arbitrary file in your build path 
-
-.. code-block:: scala
-
-    linuxPackageMappings += {
-      val file = sourceDirectory.value / "resources" / "somefile.txt"
-      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.
-
-.. code-block:: scala
-
-    linuxPackageMappings in Debian += {
-      val file = sourceDirectory.value / "resources" / "debian-somefile.txt"
-      packageMapping( (file, "/absolute/path/somefile.txt") )
-    }
-    
-    linuxPackageMappings in Rpm += {
-      val file = sourceDirectory.value / "resources" / "rpm-somefile.txt"
-      packageMapping( (file, "/absolute/path/somefile.txt") )
-    }
-
-
-Filter/Remove Mappings
-~~~~~~~~~~~~~~~~~~~~~~
-
-If you want to remove some mappings you have to filter the current list of ``linuxPackageMappings``.
-As ``linuxPackageMappings`` is a task, the order of your settings is important. Here are some examples
-on how to filter mappings.
-
-.. code-block:: scala
-
-    // this is equal to 
-    // linuxPackageMappings <<= linuxPackageMappings map { mappings => /* stuff */ mappings }
-    linuxPackageMappings := { 
-        // first get the current mappings. mapping is of type Seq[LinuxPackageMapping]
-        val mappings = linuxPackageMappings.value
-        // map over the mappings if you want to change them
-        mappings map { mapping =>
-            // we remove everything besides files that end with ".conf"
-            val filtered = mapping.mappings filter {
-                case (file, name) => name endsWith ".conf"
-            }
-            // now we copy the mapping but replace the mappings
-            mapping.copy(mappings = filtered)
-        } filter {
-            // remove all LinuxPackageMapping instances that have to file mappings
-            _.mappings.nonEmpty
-        } 
-    }
-    
-Alter LinuxPackageMapping
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First we alter the permissions for all ``LinuxPackageMapping``s that match a specific criteria.
-
-.. code-block:: scala
-
-    // Altering permissions for configs
-    linuxPackageMappings := {
-        val mappings = linuxPackageMappings.value
-        // Changing the group for all configs
-        mappings map { 
-            case linuxPackage if linuxPackage.fileData.config equals "true" =>
-                // altering the group
-                val newFileData = linuxPackage.fileData.copy(
-                    group = "appdocs"
-                )
-                // altering the LinuxPackageMapping
-                linuxPackage.copy(
-                    fileData = newFileData
-                )
-            case linuxPackage => linuxPackage
-        }
-    }
-
-Alter LinuxSymlinks
-~~~~~~~~~~~~~~~~~~~
-
-First we alter the permissions for all ``LinuxPackageMapping``s that match a specific criteria.
-
-.. code-block:: scala
-
-    // The same as linuxPackageMappings
-    linuxPackageSymlinks := {
-        val links = linuxPackageSymlinks.value
-        
-        links filter { /* remove stuff */ } map { /* change stuff */}
-    }
-
-.. toctree::
-   :maxdepth: 2
-   
-   debian.rst
-   redhat.rst
diff --git a/src/sphinx/DetailedTopics/redhat.rst b/src/sphinx/DetailedTopics/redhat.rst
deleted file mode 100644
index abb9f7dd1..000000000
--- a/src/sphinx/DetailedTopics/redhat.rst
+++ /dev/null
@@ -1,209 +0,0 @@
-RedHat
-======
-
-RedHat ``rpm`` files support a very advanced number of features.  To take full advantage of this environment, it's best to understand how the ``rpm`` package system works.  http://fedoraproject.org/wiki/How_to_create_an_RPM_package is a good tutorial, but it focuses on building packages from source.   The sbt-native-packager takes the approach that SBT has built your source and generated 'binary' packages.
-
-Settings
---------
-
-Rpms require the following specific settings:
-
-.. code-block:: scala
-
-    name in Rpm := "sbt",
-    version in Rpm <<= sbtVersion.identity,
-    rpmRelease := "1",
-    rpmVendor := "typesafe",
-    rpmUrl := Some("http://github.com/paulp/sbt-extras"),
-    rpmLicense := Some("BSD"),
-    rpmChangelogFile := Some("changelog")
-
-
-Informational Settings
-~~~~~~~~~~~~~~~~~~~~~~
-
-  ``name in Rpm``
-    The name of the package for rpm (if different from general linux name).
-
-  ``version in Rpm``
-    The version of the package for rpm (if different from general version).  Takes the form ``x.y.z``.
-
-  ``rpmRelease``
-    A release number the denotes the `rpm` version relative to the underlying software.
-
-  ``rpmVendor``
-    The name of the company/user generating the RPM.
-
-  ``rpmUrl``
-    A url associated with the software in the RPM.
-
-  ``rpmLicense``
-    The license associated with software in the RPM.
-
-Dependency Settings
-~~~~~~~~~~~~~~~~~~~
-
-  ``rpmRequirements``
-    The RPM packages that are required to be installed for this RPM to work.
-    
-    ``rpmProvides``
-    The RPM package names that this RPM provides.
-    
-    ``rpmPrerequisites``
-    The RPM packages this RPM needs before installation
-    
-    ``rpmObsoletes``
-    The packages this RPM allows you to remove
-    
-    ``rpmConflcits``
-    The packages this RPM conflicts with and cannot be installed with.
-
-Meta Settings
-~~~~~~~~~~~~~
-
-    ``rpmPrefix``
-    The path passed set as the base for the revocable package
-
-    ``rpmChangelogFile``
-    External file to be imported and used to generate the changelog of the RPM.
-
-
-Scriptlet Settings
-~~~~~~~~~~~~~~~~~~
-    
-    ``rpmPretrans`` 
-    The ``%pretrans`` scriptlet to run.
-    
-    ``rpmPre``
-    The ``%pre`` scriptlet to run.
-    
-    ``rpmVerifyScript``
-    The ``%verifyscript%`` scriptlet to run
-    
-    ``rpmPost``
-    The ``%post`` scriptlet to run
-    
-    ``rpmPosttrans``
-    The ``%posttrans`` scriptlet to run
-    
-    ``rpmPreun``
-    The ``%preun`` scriptlet to run.
-    
-    ``rpmPostun``
-    The ``%postun`` scriptlet to run.
-    
-    ``rpmBrpJavaRepackJars``
-    appends ``__os_install_post`` scriplet to ``rpmPre`` avoiding jar repackaging
-
-
-Tasks
------
-
-The Rpm support grants the following commands:
-
-  ``rpm:package-bin``
-    Generates the ``.rpm`` package for this project.
-
-  ``rpm:rpmlint``
-    Generates the ``.rpm`` file and runs the ``rpmlint`` command to look for issues in the package.  Useful for debugging.
-
-
-Rpm Prefix
-----------
-The rpm prefix allows you to create a relocatable package as defined by http://www.rpm.org/max-rpm/s1-rpm-reloc-prefix-tag.html.  This optional setting with a handful of overrides to scriptlets and templates will allow you to create a working java_server archetype that can be relocated in the file system.  
-
-Example Settings
-~~~~~~~~~~~~~~~~~~
-
-.. code-block:: scala
-
-    defaultLinuxInstallLocation := "/opt/package_root",
-    rpmPrefix := Some(defaultLinuxInstallLocation),
-    linuxPackageSymlinks := Seq.empty,
-    defaultLinuxLogsLocation := defaultLinuxInstallLocation + "/" + name
-  
-
-rpmChangelogFile
-----------------
-The rpmChangelogFile property allows you to set a source that will be imported and used on the RPM generation. So if you use rpm commands to see the changelog it brings that information. You have to create the content on that file following the RPM conventions that are available here http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs.
-
-Example Settings
-~~~~~~~~~~~~~~~~~~
-
-.. code-block:: scala
-
-    changelog := "changelog.txt",
-    rpmChangelogFile := Some(changelog)
-
-
-.. code-block:: txt
-    * Sun Aug 24 2014 Team <contact@example.com> - 1.1.0
-    -Allow to login using social networks
-    * Wed Aug 20 2014 Team <contact@example.com> - 1.0.1
-    -Vulnerability fix.
-    * Tue Aug 19 2014 Team <contact@example.com> - 1.0.0
-    -First version of the system
-
-
-Template Changes
-~~~~~~~~~~~~~~~~~~
-Apply the following changes to the default init start script.  You can find this in the sbt-native-packager source.
-
-
-``src/templates/start``
-
-.. code-block:: bash
-    
-    ...
-    [ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog
- 
-    # smb could define some additional options in $RUN_OPTS
-    RUN_CMD="${PACKAGE_PREFIX}/${{app_name}}/bin/${{app_name}}"
-    ...
-
-
-
-Scriptlet Changes
-~~~~~~~~~~~~~~~~~~
-Apply the following changes to the scriptlets that can be found in the sbt-native-packager source.
-
-``src/rpm/scriptlets/post-rpm``
-
-.. code-block:: bash
-
-    ...
-    echo "PACKAGE_PREFIX=${RPM_INSTALL_PREFIX}" > /etc/sysconfig/${{app_name}}
-    ...
-
-``src/rpm/scriptlets/preun-rpm``
-
-.. code-block:: bash
-
-    ...
-    rm /etc/sysconfig/${{app_name}}
-    ...
-
-
-    
-Jar Repackaging
----------------
-
-rpm repackages jars by default (described in this `blog post`_) in order to optimize jars.
-This behaviour is turned off by default with this setting.
-
-.. code-block:: scala
-
-    rpmBrpJavaRepackJars := false
-    
-Note that this appends content to your ``rpmPre`` definition, so make sure not to override it.
-For more information on this topic follow these links:
-
-* `issue #195`_
-* `pullrequest #199`_
-* `OpenSuse issue`_
-
-  .. _blog post: http://swaeku.github.io/blog/2013/08/05/how-to-disable-brp-java-repack-jars-during-rpm-build
-  .. _issue #195: https://github.com/sbt/sbt-native-packager/issues/195
-  .. _pullrequest #199: https://github.com/sbt/sbt-native-packager/pull/199
-  .. _OpenSuse issue: https://github.com/sbt/sbt-native-packager/issues/215
-  
diff --git a/src/sphinx/DetailedTopics/universal.rst b/src/sphinx/DetailedTopics/universal.rst
deleted file mode 100644
index 07c177227..000000000
--- a/src/sphinx/DetailedTopics/universal.rst
+++ /dev/null
@@ -1,310 +0,0 @@
-.. _Universal:
-
-Universal
-=========
-
-Universal packaging just takes a plain ``mappings`` configuration and generates various 
-package files for distribution.  It allows you to provide your users a distribution
-that is not tied to any particular platform, but may require manual labor to set up.
-
-
-Getting Started with Universal Packaging
-----------------------------------------
-By default, all files found in the ``src/universal`` directory are included in the distribution.  So, the first step
-in creating a a distribution is to place files in this directory in the layout you would like in the distributed zip file.
-
-To add build generated files to the distribution, simple add a *mapping* to the ``mappings in Universal`` setting.  Let's
-look at an example where we add the packaged jar of a project to the lib folder of a distribution:
-
-.. code-block:: scala
-
-    mappings in Universal <+= (packageBin in Compile) map { jar =>
-      jar -> ("lib/" + jar.getName)
-    }
-
-The above does two things:  
-
-1. It depends on ``packageBin in Compile`` which will generate a jar file form the project.
-2. It creates a *mapping* (a ``Tuple2[File, String]``) which denotes the file and the location in the distribution as a string.
-
-You can use this to add anything you desire to the package.
-
-**Note**
-
-..
-
-    If you are using an ``application archetype`` or the ``playframework``, the jar mapping is already defined and
-    you should not include these in your ``build.sbt``. `issue 227`_
-    
-.. _issue 227: https://github.com/sbt/sbt-native-packager/issues/227
-
-
-Universal Conventions
----------------------
-This plugin has a set of conventions for universal packages that enable the automatic generation of native packages.  The
-universal convention has the following package layout:
-
-
-.. code-block:: none
-
-    bin/
-       <scripts and things you want on the path>
-    lib/
-       <shared libraries>
-    conf/
-       <configuration files that should be accessible using platform standard config locations.>
-    doc/
-       <Documentation files that should be easily accessible. (index.html treated specially)>
-
-If your plugin matches these conventions, you can enable the settings to automatically generate native layouts based on your universal package.  To do
-so, add the following to your build.sbt:
-
-
-.. code-block:: scala
-
-    mapGenericFilesToLinux
-
-    mapGenericFilesToWinows
-
-
-In Linux, this mapping creates symlinks from platform locations to the install location of the universal package.  For example, 
-given the following packaging:
-
-
-.. code-block:: none
-
-    bin/
-       cool-tool
-    lib/
-       cool-tool.jar
-    conf/
-       cool-tool.conf
-
-
-The ``mapGenericFilesToLinux`` settings will create the following package (symlinks denoted with ``->``):
-
-
-.. code-block:: none
-
-    /usr/share/<pkg-name>/
-       bin/
-         cool-tool
-       lib/
-         cool-tool.jar
-       conf/
-         cool-tool.conf
-    /usr/bin/
-         cool-tool  -> /usr/share/<package-name>/bin/cool-tool
-    /etc/<pkg-name> -> /usr/share/<package-name>/conf
-
-The ``mapGenericFilesToWindows`` will construct an MSI that installs the application in ``<Platform Program Files>\<Package Name>`` and include
-the ``bin`` directory on Windows ``PATH`` environment variable (optionally disabled).  While these mappings provide a great start to nice packaging, it still
-may be necessary to customize the native packaging for each platform.   This can be done by configuring those settings directly.
-
-For example, even using generic mapping, debian has a requirement for changelog files to be fully formed.  Using the above generic mapping, we can configure just this
-changelog in addition to the generic packaging by first defining a changelog in ``src/debian/changelog`` and then adding the following setting:
-
-
-.. code-block:: scala
-
-    linuxPackageMappings in Debian <+= (name in Universal, sourceDirectory in Debian) map { (name, dir) =>
-      (packageMapping(
-        (dir / "changelog") -> "/usr/share/doc/sbt/changelog.gz"
-      ) withUser "root" withGroup "root" withPerms "0644" gzipped) asDocs()
-    }
-
-Notice how we're *only* modifying the package mappings for Debian linux packages.  For more information on the underlying packaging settings, see
-:ref:`Windows` and :ref:`Linux` documentation.
-
-
-
-Configurations
---------------
-Universal packaging provides three Configurations:
-
-  ``universal``
-    For creating full distributions
-  ``universal-docs``
-    For creating bundles of documentation
-  ``universal-src``
-    For creating bundles of source.
-
-
-Settings
---------
-As we showed before, the Universal packages are completely configured through the use of the mappings key.  Simply
-specify the desired mappings for a given configuration.  For Example:
-
-.. code-block:: scala
-
-    mappings in Universal <+= packageBin in Compile map { p => p -> "lib/foo.jar" }
-
-However, sometimes it may be advantageous to customize the files for each archive separately.  For example, perhaps 
-the .tar.gz has an additional README plaintext file in additon to a README.html.  To add this just to the .tar.gz file,
-use the task-scope feature of sbt:
-
-.. code-block:: scala
-
-    mappings in Universal in package-zip-tarball += file("README") -> "README"
-    
-Besides ``mappings``, the ``name``, ``sourceDirectory`` and ``target`` configurations are all respected by universal packaging.
-
-**Note: The Universal plugin will make anything in a bin/ directory executable.  This is to work around issues with JVM and file system manipulations.**
-
-MappingsHelper
---------------
-
-The `MappingsHelper`_ class provides a set of helper functions to make mapping directories easier.
-
-.. code-block:: scala
-
-    import com.typesafe.sbt.SbtNativePackager._
-    import NativePackagerHelper._
-    
-    mappings in Universal ++= directory("src/main/resources/cache")
-    
-    mappings in Universal ++= contentOf("src/main/resources/docs")
-    
-    mappings in Universal <++= sourceDirectory map (src => directory(src / "main" / "resources" / "cache"))
-    
-    mappings in Universal <++= sourceDirectory map (src => contentOf(src / "main" / "resources" / "docs"))
-
-
-.. _MappingsHelper: https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/MappingsHelper.scala
-
-Mapping Examples
-----------------
-
-SBT provides and IO and `Path`_ API, which
-lets you define custom mappings easily. The files will appear in the generate universal zip, but also in your
-debian/rpm/msi/dmg builds as described above in the conventions.
-
-.. _Path: http://www.scala-sbt.org/0.13.1/docs/Detailed-Topics/Paths.html
-
-The ``packageBin in Compile`` dependency is only needed, if your files get generated
-during the ``packageBin`` command or before. For static files you can remove it.
-
-Mapping a complete directory
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: scala
-
-    mappings in Universal <++= (packageBin in Compile, target ) map { (_, target) =>
-        val dir = target / "scala-2.10" / "api"
-        (dir.***) pair relativeTo(dir.getParentFile)
-    } 
-
-This maps the ``api`` folder directly to the generate universal zip. ``dir.***`` is a short way for
-``dir ** "*"``, which means _select all files including *dir*. ``relativeTo(dir.getParentFile)``
-generates a function with a ``file -> Option[String]`` mapping, which tries to generate a relative
-string path from ``dir.getParentFile`` to the passed in file. ``pair`` uses the ``relativeTo``
-function to generate a mapping ``File -> String``, which is *your file* to *relative destination*.
-
-It exists some helper methods to map a complete directory in more human readable way.
-
-.. code-block:: scala
-
-    import com.typesafe.sbt.SbtNativePackager._
-    import NativePackagerHelper._
-
-    //For dynamic content, e.g. something in the target directory which depends on a Task
-    mappings in Universal <++= (packageBin in Compile, target) map { (_, target) =>
-      directory(target / "scala-2.10" / "api")
-    }
-
-    //For static content it can be added to mappings directly
-    mappings in Universal ++= directory("SomeResourcesToInclude")
-
-
-Mapping the content of a directory
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. code-block:: scala
-
-    mappings in Universal <++= (packageBin in Compile, target ) map { (_, target) =>
-        val dir = target / "scala-2.10" / "api"
-        (dir.*** --- dir) pair relativeTo(dir)
-    }
-    
-The ``dir`` gets excluded and is used as root for ``relativeTo(dir)``.
-
-Filter/Remove mappings
-^^^^^^^^^^^^^^^^^^^^^^
-
-If you want to remove mappings, you have to filter the current list of mappings.
-This example demonstrates how to build a fat jar with sbt-assembly, but using all
-the convenience of the sbt native packager archetypes.
-
-tl;dr how to remove stuff
-
-.. code-block:: scala
-
-    // removes all jar mappings in universal and appends the fat jar
-    mappings in Universal := {
-        // universalMappings: Seq[(File,String)]
-        val universalMappings = (mappings in Universal).value 
-        val fatJar = (assembly in Compile).value
-        // removing means filtering
-        val filtered = universalMappings filter { 
-            case (file, name) =>  ! name.endsWith(".jar") 
-        }
-        // add the fat jar
-        filtered :+ (fatJar -> ("lib/" + fatJar.getName))
-    }
-    
-    // sbt 0.12 syntax
-    mappings in Universal <<= (mappings in Universal, assembly in Compile) map { (universalMappings, fatJar) => /* same logic */}
-
-
-The complete ``build.sbt`` should contain these settings if you want a single assembled fat jar.
-
-.. code-block:: scala
-
-    // the assembly settings
-    assemblySettings
-
-    // we specify the name for our fat jar
-    jarName in assembly := "assembly-project.jar"
-
-    // using the java server for this application. java_application would be fine, too
-    packageArchetype.java_server
-
-    // removes all jar mappings in universal and appends the fat jar
-    mappings in Universal := {
-        val universalMappings = (mappings in Universal).value 
-        val fatJar = (assembly in Compile).value
-        val filtered = universalMappings filter { 
-            case (file, name) =>  ! name.endsWith(".jar") 
-        }
-        filtered :+ (fatJar -> ("lib/" + fatJar.getName))
-    }
-
-    // the bash scripts classpath only needs the fat jar
-    scriptClasspath := Seq( (jarName in assembly).value )
-    
-
-Commands
---------
-
-  ``universal:package-bin``
-    Creates the ``zip`` universal package.
-  
-  ``universal:package-zip-tarball``
-    Creates the ``tgz`` universal package.
-    
-  ``universal:package-xz-tarball``
-    Creates the ``txz`` universal package.  The ``xz`` command can get better compression
-    for some types of archives.
-
-  ``universal:package-osx-dmg``
-    Creates the ``dmg`` universal package.  This only work on OSX or systems with ``hdiutil``.
-    
-  ``universal-docs:package-bin``
-    Creates the ``zip`` universal documentation package.
-  
-  ``universal-docs:package-zip-tarball``
-    Creates the ``tgz`` universal documentation package.
-    
-  ``universal-docs:package-xz-tarball``
-    Creates the ``txz`` universal documentation package.  The ``xz`` command can get better compression
-    for some types of archives.
diff --git a/src/sphinx/DetailedTopics/windows.rst b/src/sphinx/DetailedTopics/windows.rst
deleted file mode 100644
index e685a7a77..000000000
--- a/src/sphinx/DetailedTopics/windows.rst
+++ /dev/null
@@ -1,130 +0,0 @@
-.. _Windows:
-
-Packaging for Windows
-=====================
-
-The windows packaging is completely tied to the WIX installer toolset.  For any non-trivial package, it's important to understand how WIX works.  http://wix.tramontana.co.hu/ is an excellent tutorial to how to create packages using wix.
-
-However, the native-packager provides a simple layer on top of wix that *may* be enough for most projects.  If it is not, just override ``wixConfig`` or ``wixFile`` settings.  Let's look at the layer above direct xml configuration.
-
-
-Feature configuration
----------------------
-The abstraction over wix allows you to configure "features" that users may optionally install.  These feature are higher level things, like a set of files or menu links.
-The currently supported compoennts of features are:
-
-1. Files (``ComponentFile``)
-2. Path Configuration (``AddDirectoryToPath``)
-3. Menu Shortcuts (``AddShortCuts``)
-
-
-To create a new feature, simple instantiate the ``WindowsFeature`` class with the desired feature components that are included.
-
-Here's an example feature that installs a binary and a script, as well as path settings:
-
-.. code-block:: scala
-
-    wixFeatures += WindowsFeature(
-        id="BinaryAndPath",
-        title="My Project's Binaries and updated PATH settings",
-        desc="Update PATH environment variables (requires restart).",
-        components = Seq(
-          ComponentFile("bin/cool.bat"),
-          ComponentFile("lib/cool.jar"),
-          AddDirectoryToPath("bin"))
-    )
-
-All file references should line up exactly with those found in the ``mappings in Windows`` configuration.   When generating an MSI, the plugin will first create
-a directory using all the ``mappings in Windows`` and configure this for inclusion in a ``cab`` file.  If you'd like to add files to include, these must *first*
-be added to the mappings, and then to a feature.   For example, if we complete the above setting to include file mappings, we'd have the following:
-
-.. code-block:: scala
-
-    mappings in Windows ++= (packageBin in Compile, sourceDirectory in Windows) map { (jar, dir) =>
-      Seq(jar -> "lib/cool.jar", (dir / "cool.bat") -> "bin/cool.bat")
-    }
-
-    wixFeatures += WindowsFeature(
-        id="BinaryAndPath",
-        title="My Project's Binaries and updated PATH settings",
-        desc="Update PATH environment variables (requires restart).",
-        components = Seq(
-          ComponentFile("bin/cool.bat"),
-          ComponentFile("lib/cool.jar"),
-          AddDirectoryToPath("bin"))
-    )
-
-Right now this layer is *very* limited in what it can accomplish, and hasn't been heavily debugged.  If you're interested in helping contribute, please
-do so!   However, for most command line tools, it should be sufficient for generating a basic ``msi`` that windows users can install.
-
-
-Now, let's look at the full set of windows settings.
-
-Settings
---------
-
-  ``name in Windows``
-    The name of the generated msi file.
-
-  ``candleOptions``
-    the list of options to pass to the ``candle.exe`` command.
-
-  ``lightOptions``
-    the list of options to pass to the ``light.exe`` command.  Most likely setting is: ``Seq("-ext", "WixUIExtension", "-cultures:en-us")`` for UI.
-
-  ``wixProductId``
-    The GUID to use to identify the windows package/product.
-
-  ``wixProductUpgradeId``
-    The GUID to use to identify the windows package/product *upgrade* identifier (see wix docs).
-
-  ``wixPackageInfo``
-    The information used to autoconstruct the ``<Product><Package/>`` portion of the wix xml.  **Note: unused if ``wixConfig`` is overridden**
-
-  ``wixProductLicense``
-    An (optional) ``rtf`` file to display as the product license during installation.  Default to looking for ``src/windows/License.rtf``
-
-  ``wixFeatures``
-    A set of windows features that users can install with this package.  **Note: unused if ``wixConfig`` is overridden**
-
-  ``wixProductConfig``
-    inline XML to use for wix configuration.  This is everything nested inside the ``<Product>`` element.
-
-  ``wixConfig``
-    inline XML to use for wix configuration.   This is used if the ``wixFile`` setting is not specified.
-
-  ``wixFile``
-    The file containing WIX xml that defines the build.
-
-  ``mappings in packageMsi in Windows``
-    A list of file->location pairs.   This list is used to move files into a location where WIX can pick up the files and generate a ``cab`` or embedded ``cab`` for the ``msi``.
-    The WIX xml should use the relative locations in this mappings when references files for the package.
-
-Commands
---------
-
-  ``windows:package-bin``
-    Creates the ``msi`` package.
-  
-  ``wix-file``
-    Generates the Wix xml file from `wixConfig` and `wixProductConfig` setings, unless overriden.
-    
-Utilities
----------
-
-The native-packager plugin provides a few handy utilities for generating Wix XML.  These
-utilities are located in the ``com.typesafe.packager.windows.WixHelper`` object.  Among
-these are the following functions:
-
-  ``cleanStringForId(String): String``
-    Takes in a string and returns a wix-friendly identifier.  Note: truncates to 50 characters.
-  
-  ``cleanFileName(String): String``
-    Takes in a file name and replaces any ``$`` with ``$$`` to make it past the Wix preprocessor.
-
-  ``generateComponentsAndDirectoryXml(File): (Seq[String], scala.xml.Node)``
-    This method will take a file and generate ``<Directory>``, ``<Component>`` and ``<File>``
-    XML elements for all files/directories contained in the given file.  It will return the
-    ``Id`` settings for any generated components.  This is a handy way to package a large
-    directory of files for usage in the Features of an MSI.
-
diff --git a/src/sphinx/archetypes/akka_app/index.rst b/src/sphinx/archetypes/akka_app/index.rst
new file mode 100644
index 000000000..3a1d1b4e9
--- /dev/null
+++ b/src/sphinx/archetypes/akka_app/index.rst
@@ -0,0 +1,2 @@
+Akka Microkernel
+################
diff --git a/src/sphinx/DetailedTopics/archetypes.rst b/src/sphinx/archetypes/index.rst
similarity index 98%
rename from src/sphinx/DetailedTopics/archetypes.rst
rename to src/sphinx/archetypes/index.rst
index 7d568eeeb..dc3b14dd2 100644
--- a/src/sphinx/DetailedTopics/archetypes.rst
+++ b/src/sphinx/archetypes/index.rst
@@ -1,5 +1,13 @@
 .. _Archetypes:
 
+
+.. toctree::
+   :maxdepth: 2
+   
+   java_app/index.rst
+   java_server/index.rst
+   akka_app/index.rst
+
 Project Archetypes
 ==================
 
diff --git a/src/sphinx/GettingStartedApplications/AddingConfiguration.rst b/src/sphinx/archetypes/java_app/AddingConfiguration.rst
similarity index 100%
rename from src/sphinx/GettingStartedApplications/AddingConfiguration.rst
rename to src/sphinx/archetypes/java_app/AddingConfiguration.rst
diff --git a/src/sphinx/GettingStartedApplications/GeneratingFiles.rst b/src/sphinx/archetypes/java_app/GeneratingFiles.rst
similarity index 100%
rename from src/sphinx/GettingStartedApplications/GeneratingFiles.rst
rename to src/sphinx/archetypes/java_app/GeneratingFiles.rst
diff --git a/src/sphinx/GettingStartedApplications/MyFirstProject.rst b/src/sphinx/archetypes/java_app/MyFirstProject.rst
similarity index 100%
rename from src/sphinx/GettingStartedApplications/MyFirstProject.rst
rename to src/sphinx/archetypes/java_app/MyFirstProject.rst
diff --git a/src/sphinx/GettingStartedApplications/OverridingTemplates.rst b/src/sphinx/archetypes/java_app/OverridingTemplates.rst
similarity index 94%
rename from src/sphinx/GettingStartedApplications/OverridingTemplates.rst
rename to src/sphinx/archetypes/java_app/OverridingTemplates.rst
index c83235582..2bd9679db 100644
--- a/src/sphinx/GettingStartedApplications/OverridingTemplates.rst
+++ b/src/sphinx/archetypes/java_app/OverridingTemplates.rst
@@ -6,10 +6,10 @@ The native packager provides a mechanism where the template used to create each
 overridden. 
 
 The easiest way to add functionality to the default script is by adding ``bashScriptExtraDefines`` :doc:`as described
-in adding configuration for applications </GettingStartedApplications/AddingConfiguration>`. Customizing the bash
+in adding configuration for applications </archetypes/java_server/AddingConfiguration>`. Customizing the bash
 script will effect all platform-specific builds. The server archetype provides a further level of customization for
 specific System Loaders and Package types. These template file are described in 
-:doc:`configuring servers </GettingStartedServers/AddingConfiguration>`.
+:doc:`configuring servers </archetypes/java_server/AddingConfiguration>`.
 
 Overriding Complete Templates
 -----------------------------
diff --git a/src/sphinx/GettingStartedApplications/WritingDocumentation.rst b/src/sphinx/archetypes/java_app/WritingDocumentation.rst
similarity index 84%
rename from src/sphinx/GettingStartedApplications/WritingDocumentation.rst
rename to src/sphinx/archetypes/java_app/WritingDocumentation.rst
index 0aaec966b..319942399 100644
--- a/src/sphinx/GettingStartedApplications/WritingDocumentation.rst
+++ b/src/sphinx/archetypes/java_app/WritingDocumentation.rst
@@ -19,7 +19,9 @@ To create a linux man page for the application, let's create a ``src/linux/usr/s
     .SH SYNOPSIS
     .B example-cli [-h]
 
-Notice the location of the file.  Any file under ``src/linux`` is automatically included, relative to ``/``, in linux packages (deb, rpm).  That means the man file will **not** appear in the universal package (confusing linux users).  
+Notice the location of the file.  Any file under ``src/linux`` is automatically included,
+relative to ``/``, in linux packages (deb, rpm).  That means the man file will **not** appear
+in the universal package (confusing linux users).  
 
 Now that the man page is created, we can use a few tasks provided to view it in sbt.  Let's look in the sbt console ::
 
@@ -51,4 +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 :doc:`Java Servers <GettingStartedServers>`, which offers a few differences in how configuration is done for packaging to underlying systems.
+That's the end fo 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.
diff --git a/src/sphinx/GettingStartedApplications/gettingstarted.rst b/src/sphinx/archetypes/java_app/gettingstarted.rst
similarity index 88%
rename from src/sphinx/GettingStartedApplications/gettingstarted.rst
rename to src/sphinx/archetypes/java_app/gettingstarted.rst
index 404fc957f..33901b5e5 100644
--- a/src/sphinx/GettingStartedApplications/gettingstarted.rst
+++ b/src/sphinx/archetypes/java_app/gettingstarted.rst
@@ -26,7 +26,7 @@ Defining a new package
 ~~~~~~~~~~~~~~~~~~~~~~
 
 To define a new package, after installing the plugin and ensuring the basic settings are on the project, start configuring your package contents
-either using :ref:`Archetypes` or :ref:`Universal` hooks.  These will describe the appropriate way to begin packaging for your applciation.
+either using :doc:`Archetypes </archetypes/index>` or :ref:`Universal` hooks.  These will describe the appropriate way to begin packaging for your application.
 
 
 
diff --git a/src/sphinx/GettingStartedApplications/index.rst b/src/sphinx/archetypes/java_app/index.rst
similarity index 90%
rename from src/sphinx/GettingStartedApplications/index.rst
rename to src/sphinx/archetypes/java_app/index.rst
index 1d439633e..dc7d9765a 100644
--- a/src/sphinx/GettingStartedApplications/index.rst
+++ b/src/sphinx/archetypes/java_app/index.rst
@@ -12,7 +12,7 @@ neeeded to generate the best package possible.
 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.
 
-Additionally there is :doc:`Server Packaging <GettingStartedServers>` which provides platform-specific
+Additionally there is :doc:`Server Packaging </archetypes/java_server/index>` which provides platform-specific
 functionality for installing your application in server environments. You can customize specific debian and rpm packaging
 for a variety of platforms and init service loaders including Upstart, System V and SystemD (experimental).
 
@@ -21,6 +21,7 @@ Sbt-Native-Packager is highly customizable and you can add or override several a
 .. toctree::
    :maxdepth: 1
    
+   gettingstarted
    MyFirstProject.rst
    AddingConfiguration.rst
    GeneratingFiles.rst
diff --git a/src/sphinx/GettingStartedServers/AddingConfiguration.rst b/src/sphinx/archetypes/java_server/AddingConfiguration.rst
similarity index 100%
rename from src/sphinx/GettingStartedServers/AddingConfiguration.rst
rename to src/sphinx/archetypes/java_server/AddingConfiguration.rst
diff --git a/src/sphinx/GettingStartedServers/MyFirstProject.rst b/src/sphinx/archetypes/java_server/MyFirstProject.rst
similarity index 97%
rename from src/sphinx/GettingStartedServers/MyFirstProject.rst
rename to src/sphinx/archetypes/java_server/MyFirstProject.rst
index 1b85fbba5..ee77ce0d2 100644
--- a/src/sphinx/GettingStartedServers/MyFirstProject.rst
+++ b/src/sphinx/archetypes/java_server/MyFirstProject.rst
@@ -1,7 +1,7 @@
 My First Packaged Server Project
 ################################
 
-Follow the instructions for the basic ``java_application`` setup in :doc:`../GettingStartedApplications/index` to get a working build and
+Follow the instructions for the basic ``java_application`` setup in :doc:`../java_app/index` to get a working build and
 understand the core concepts of sbt-native-packager. Based on this configuration we exchange
 in our ``build.sbt``
 
@@ -68,7 +68,7 @@ this `native packager discussion`_.
 .. _native packager discussion: https://github.com/sbt/sbt-native-packager/pull/174
 
 If you want to change something in this predefined structure read more about it in
-the :doc:`linux section </DetailedTopics/linux>`.
+the :doc:`linux section </formats/linux>`.
 
 Debian (.deb)
 =============
diff --git a/src/sphinx/GettingStartedServers/OverridingTemplates.rst b/src/sphinx/archetypes/java_server/OverridingTemplates.rst
similarity index 98%
rename from src/sphinx/GettingStartedServers/OverridingTemplates.rst
rename to src/sphinx/archetypes/java_server/OverridingTemplates.rst
index 0071ff98b..ce470f050 100644
--- a/src/sphinx/GettingStartedServers/OverridingTemplates.rst
+++ b/src/sphinx/archetypes/java_server/OverridingTemplates.rst
@@ -1,7 +1,7 @@
 Overriding templates
 ####################
 
-Some scripts are covered in the standard application type. Read more on :doc:`../GettingStartedApplications/OverridingTemplates`.
+Some scripts are covered in the standard application type. Read more on :doc:`../java_app/OverridingTemplates`.
 For the ``java_server`` package lifecycle scripts are customized to provide the following additional features
 
 * Chowning directories and files correctly
diff --git a/src/sphinx/GettingStartedServers/index.rst b/src/sphinx/archetypes/java_server/index.rst
similarity index 93%
rename from src/sphinx/GettingStartedServers/index.rst
rename to src/sphinx/archetypes/java_server/index.rst
index 989db9efe..68b815197 100644
--- a/src/sphinx/GettingStartedServers/index.rst
+++ b/src/sphinx/archetypes/java_server/index.rst
@@ -1,11 +1,18 @@
 Getting Started with Servers
 ############################
 
+.. toctree::
+   :maxdepth: 1
+   
+   MyFirstProject.rst
+   AddingConfiguration.rst
+   OverridingTemplates.rst
+
 The sbt-native-packager is an sbt plugin for bundling your server for a variety of platforms.  
 
 **Note:** Please follow the :ref:`Installation` instructions for how to set it up on a project.
 
-In the :doc:`Application Packaging <GettingStartedApplications>` section we described how to build and
+In the :doc:`Application Packaging </archetypes/java_app/index>` section we described how to build and
 customize settings related to the application. Sbt-Native-Packager provides a further level for servers
 which define how applications are installed and initialized for various platforms. 
 be customized for specific platforms. While it provides
@@ -78,7 +85,8 @@ which will add the following resource file to use start/stop instead of initctl
       stop $app_name 
   }
 
-The :doc:`debian <DetailedTopics/debian>` and :doc:`redhat </DetailedTopics/redhat>` pages have further information on overriding distribution scpecific actions.
+The :doc:`debian </formats/debian>` and :doc:`redhat </formats/rpm>` pages have further information on overriding 
+distribution scpecific actions.
 
 SystemD Support
 ================
diff --git a/src/sphinx/formats/docker.rst b/src/sphinx/formats/docker.rst
index d6a78d7b0..f2660c898 100644
--- a/src/sphinx/formats/docker.rst
+++ b/src/sphinx/formats/docker.rst
@@ -8,6 +8,7 @@ Docker images describe how to set up a container for running an application, inc
 
   sbt-native-packager focuses on creating a Docker image which can "just run" the application built by SBT.
   
+  
 .. contents:: 
   :depth: 2
 
@@ -16,6 +17,10 @@ Requirements
 
 You need the docker console client installed. SBT Native Packager doesn't use the REST API.
 
+It is currently not possible to provide authentication for Docker repositories from within the build.
+The ``docker`` binary used by the build should already have been configured with the appropriate
+authentication details. See https://docs.docker.com/reference/commandline/cli/#login.
+
 
 Build
 -----
diff --git a/src/sphinx/formats/index.rst b/src/sphinx/formats/index.rst
new file mode 100644
index 000000000..bb8cfc7fb
--- /dev/null
+++ b/src/sphinx/formats/index.rst
@@ -0,0 +1,14 @@
+Packaging Formats
+#################
+
+
+
+.. toctree::
+   :maxdepth: 2
+   
+   universal.rst
+   linux.rst
+   debian.rst
+   rpm.rst
+   docker.rst
+   windows.rst
diff --git a/src/sphinx/formats/linux.rst b/src/sphinx/formats/linux.rst
index 47c47a6b7..6552e722d 100644
--- a/src/sphinx/formats/linux.rst
+++ b/src/sphinx/formats/linux.rst
@@ -337,7 +337,7 @@ on how to filter mappings.
 Alter LinuxPackageMapping
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-First we alter the permissions for all ``LinuxPackageMapping``s that match a specific criteria.
+First we alter the permissions for all ``LinuxPackageMapping`` s that match a specific criteria.
 
 .. code-block:: scala
 
@@ -362,7 +362,7 @@ First we alter the permissions for all ``LinuxPackageMapping``s that match a spe
 Alter LinuxSymlinks
 ~~~~~~~~~~~~~~~~~~~
 
-First we alter the permissions for all ``LinuxPackageMapping``s that match a specific criteria.
+First we alter the permissions for all ``LinuxPackageMapping`` s that match a specific criteria.
 
 .. code-block:: scala
 
diff --git a/src/sphinx/formats/rpm.rst b/src/sphinx/formats/rpm.rst
index 4b70693e0..3fe168fd1 100644
--- a/src/sphinx/formats/rpm.rst
+++ b/src/sphinx/formats/rpm.rst
@@ -207,7 +207,8 @@ Example Settings:
     rpmChangelogFile := Some(changelog)
 
 
-.. code-block:: txt
+.. code-block:: bash
+
     * Sun Aug 24 2014 Team <contact@example.com> - 1.1.0
     -Allow to login using social networks
     * Wed Aug 20 2014 Team <contact@example.com> - 1.0.1
diff --git a/src/sphinx/formats/universal.rst b/src/sphinx/formats/universal.rst
index 2e489971d..a6ea0987d 100644
--- a/src/sphinx/formats/universal.rst
+++ b/src/sphinx/formats/universal.rst
@@ -46,33 +46,29 @@ Build
 
 There is a task for each output format
 
-Zip
-~~~
-
-.. code-block:: bash
-
-  sbt universal:packageBin
-
-Tar
-~~~
-
-.. code-block:: bash
-
-  sbt universal:packageZipTarball
+  **Zip**
+  
+  .. code-block:: bash
+  
+    sbt universal:packageBin
+  
+  **Tar**
+  
+  .. code-block:: bash
 
-Xz
-~~
+    sbt universal:packageZipTarball
 
-.. code-block:: bash
+  **Xz**
 
-  sbt universal:packageXzTarball
+  .. code-block:: bash
 
-Dmg
-~~~
+    sbt universal:packageXzTarball
 
-.. code-block:: bash
+  **Dmg**
 
-  sbt universal:packageOsxDmg
+  .. code-block:: bash
+  
+    sbt universal:packageOsxDmg
 
 
 Required Settings
@@ -288,11 +284,24 @@ MappingsHelper
 
 The `MappingsHelper`_ class provides a set of helper functions to make mapping directories easier.
 
-.. code-block:: scala
-
+  **sbt 0.13.5 and plugin 1.0.x or higher**
+  
+  .. code-block:: scala
+    
+      import NativePackagerHelper._
+    
+  **plugin  version 0.8.x or lower**
+  
+  .. code-block:: scala
+    
     import com.typesafe.sbt.SbtNativePackager._
     import NativePackagerHelper._
-    
+
+
+You get a set of methods which will help you to create mappings very easily.
+
+.. code-block:: scala
+
     mappings in Universal ++= directory("src/main/resources/cache")
     
     mappings in Universal ++= contentOf("src/main/resources/docs")
@@ -302,7 +311,7 @@ The `MappingsHelper`_ class provides a set of helper functions to make mapping d
     mappings in Universal <++= sourceDirectory map (src => contentOf(src / "main" / "resources" / "docs"))
 
 
-.. _MappingsHelper: https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/MappingsHelper.scala
+.. _MappingsHelper: http://www.scala-sbt.org/sbt-native-packager/latest/api/#com.typesafe.sbt.packager.MappingsHelper$
 
 Mapping Examples
 ~~~~~~~~~~~~~~~~
@@ -336,9 +345,6 @@ It exists some helper methods to map a complete directory in more human readable
 
 .. code-block:: scala
 
-    import com.typesafe.sbt.SbtNativePackager._
-    import NativePackagerHelper._
-
     //For dynamic content, e.g. something in the target directory which depends on a Task
     mappings in Universal <++= (packageBin in Compile, target) map { (_, target) =>
       directory(target / "scala-2.10" / "api")
diff --git a/src/sphinx/gettingstarted.rst b/src/sphinx/gettingstarted.rst
index d749c2c9b..e67bd5585 100644
--- a/src/sphinx/gettingstarted.rst
+++ b/src/sphinx/gettingstarted.rst
@@ -1,6 +1,7 @@
 .. _GettingStarted:
 
 .. contents:: 
+  :depth: 2
 
 Installation
 ============
@@ -18,14 +19,19 @@ in the operating system specific sections.
 Version 1.0 and greater
 -----------------------
 
-If you use sbt 0.13.5 or greater you can
-enable sbt native packager by enabling it in your``build.sbt``
+If you use sbt 0.13.5 or greater you can enable sbt native packager by enabling it in your ``build.sbt``.
+We recommend to `use an archetype <archetypes/>`_ for setting up your build
+
+.. code-block:: scala
+
+  enablePlugins(JavaAppPackaging)
+
+but if you only want the bare minimum you can only add the packager plugin
 
 .. code-block:: scala
 
   enablePlugins(SbtNativePackager)
   
-  
 The autoplugins mechanism will import everything automatically.
 
 Build.scala
@@ -50,54 +56,108 @@ keys yourself. In your ``build.sbt`` or ``Build.scala`` add
 
   import com.typesafe.sbt.SbtNativePackager._
   import NativePackagerKeys._
-  
+
 
 
 Packaging Formats
 =================
 
 
-Windows
--------
-
-Creating Windows ``msi`` packages requires the use of the Windows Installer Xml utilities.  These are available for download here: http://wix.sourceforge.net/downloadv35.html.  The plugin has only been tested with version 3.5+.
-
-
-RedHat/RPM-based linux distros
-------------------------------
-
-Creating ``rpm`` packages requires the use of the following command line tools:
-
-- ``rpmbuild``
-- ``rpm`` (optional)
-- ``rpmlint`` (optional)
-
-
-Debian-based linux distros
---------------------------
-
-Creating ``deb`` packages requires the use of the following command line tools:
-
-- ``dpkg-deb``
-- ``fakeroot``
-- ``chmod``
-- ``lintian`` (optional)
-
-Universal
----------
-
-Creating ``tgz`` or ``txz`` requires the use of the following command line tools:
-
-- ``gzip``
-- ``xz``
-- ``tar``
-
-Docker
-------
-
-Creating Docker images requires the use of the following command line tools:
-
-- ``docker``
-
-It is currently not possible to provide authentication for Docker repositories from within the build. The ``docker`` binary used by the build should already have been configured with the appropriate authentication details.
-See https://docs.docker.com/reference/commandline/cli/#login.
+.. raw:: html
+
+  <hr>
+  <div class="row">
+      <div class="col-lg-3">
+        <h2>*.deb</h2>
+        <p>Packaging format for Debian based systems like Ubuntu</p>
+        <pre>debian:packageBin</pre>
+        <a class="btn btn-primary btn-lg" href="formats/debian.html" role="button"><i class="fa fa-linux"></i> Debian Plugin »</a>
+      </div>
+      <div class="col-lg-3">
+        <h2>*.rpm</h2>
+        <p>Packaging format for Redhat based systems like RHEL or CentOS.</p>
+        <pre>rpm:packageBin</pre>
+        <a class="btn btn-primary btn-lg" href="formats/rpm.html" role="button"><i class="fa fa-linux"></i> Rpm Plugin »</a>
+      </div>
+      <div class="col-lg-3">
+        <h2>*.msi</h2>
+        <p>Packaging format for windows systems.</p>
+        <pre>windows:packageBin</pre>
+        <a class="btn btn-primary btn-lg" href="formats/windows.html" role="button"><i class="fa fa-windows"></i> Windows Plugin »</a>
+      </div>
+      <div class="col-lg-3">
+        <h2>*.dmg</h2>
+        <p>Packaging format for osx based systems.</p>
+        <pre>universal:packageOsxDmg</pre>
+        <a class="btn btn-primary btn-lg" href="formats/universal.html" role="button"><i class="fa fa-apple"></i> Universal Plugin »</a>
+      </div>
+    </div>
+    <div class="row">
+      <div class="col-lg-3">
+        <h2>docker</h2>
+        <p>Package your application in a docker container.</p>
+        <pre>docker:publishLocal</pre>
+        <a class="btn btn-primary btn-lg" href="formats/docker.html" role="button"><i class="fa fa-file-archive-o"></i> Docker Plugin »</a>
+      </div>
+      <div class="col-lg-3">
+        <h2>*.zip</h2>
+        <p>Packaging format for all systems supporting zip.</p>
+        <pre>universal:packageBin</pre>
+        <a class="btn btn-primary btn-lg" href="formats/universal.html" role="button"><i class="fa fa-file-archive-o"></i> Universal Plugin »</a>
+      </div>
+      <div class="col-lg-3">
+        <h2>*.tar</h2>
+        <p>Packaging format for all systems supporting tar.</p>
+        <pre>universal:packageZipTarball</pre>
+        <a class="btn btn-primary btn-lg" href="formats/universal.html" role="button"><i class="fa fa-file-archive-o"></i> Universal Plugin »</a>
+      </div>
+      <div class="col-lg-3">
+        <h2>*.xz</h2>
+        <p>Packaging format for all systems supporting xz.</p>
+        <pre>universal:packageXzTarball</pre>
+        <a class="btn btn-primary btn-lg" href="formats/universal.html" role="button"><i class="fafa-file-archive-o"></i> Universal Plugin »</a>
+      </div>
+    </div>
+    
+    <link href="//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
+
+Archetypes
+==========
+
+
+.. raw:: html
+
+  <hr>
+  <div class="row">
+      <div class="col-lg-4">
+        <h2>Java Application</h2>
+        <p>Creates a standalone package with an executable bash/bat script.<br>&nbsp; </p>
+        <pre>enablePlugins(JavaAppPackaging)</pre>
+        <a class="btn btn-primary btn-lg" href="archetypes/java_app/" role="button"><i class="fa fa-play-circle-o"></i> Learn more »</a>
+      </div>
+      <div class="col-lg-4">
+        <h2>Java Server</h2>
+        <p>Creates a standalone package with an executabl bash/bat script and additional configuration and autostart.</p>
+        <pre>enablePlugins(JavaServerAppPackaging)</pre>
+        <a class="btn btn-primary btn-lg" href="archetypes/java_server/" role="button"><i class="fa fa-gears"></i> Learn more »</a>
+      </div>
+      <div class="col-lg-4">
+        <h2>Akka Microkernel</h2>
+        <p>Like a the Java Application archetype, but instantiates and runs a subclass of 
+        <a href="https://github.com/akka/akka/blob/master/akka-kernel/src/main/scala/akka/kernel/Main.scala">Bootable</a><br>&nbsp;</p>
+        <pre>enablePlugins(AkkaAppPackaging)</pre>
+        <a class="btn btn-primary btn-lg" href="archetypes/akka_app/" role="button"><i class="fa fa-cubes"></i> Learn more »</a>
+      </div>
+    </div>
+    
+    
+    
+Sitemap
+=======
+
+.. toctree::
+   :maxdepth: 2
+   
+   archetypes/index.rst
+   formats/index.rst
+   topics/index.rst
diff --git a/src/sphinx/index.rst b/src/sphinx/index.rst
index f7d5bfbd6..86318127a 100644
--- a/src/sphinx/index.rst
+++ b/src/sphinx/index.rst
@@ -1,9 +1,11 @@
+.. title:: SBT Native Packager
+
 .. raw:: html
 
   <div class="jumbotron" style="margin-top:-20px">
           <h1>SBT Native Packager Plugin</h1>
           <p>This sbt plugin provides you with everything you need to package your application.
-          No matther if you want to build a simple standalone application or a server application.
+          No matter if you want to build a simple standalone application or a server application.
           The JVM let's you run anywhere. SBT Native Packager let's you deploy everywhere!</p>
           <p><a class="btn btn-primary btn-lg" href="gettingstarted.html" role="button">Getting Started »</a></p>
       </div>
@@ -30,7 +32,7 @@
           The most common archtypes
           are <code>JavaAppPackaging</code> and <code>JavaServerAppPackaging</code>.
           Each archetype adds possible new settings which you can adapt to your need.<br>&nbsp;</p>
-          <p><a class="btn btn-default" href="#" role="button">Learn more »</a></p>
+          <p><a class="btn btn-default" href="archetypes/" role="button">Learn more »</a></p>
        </div>
         <div class="col-md-4">
           <h2>Formats & Customize</h2>
@@ -41,8 +43,8 @@
           <p>An archetype doesn't cover what you need? No problem. SBT Native Packager i
           build on top of some simple principles and you can customize it in many ways.
           Adding a custom packaging format or some special files.</p>
-          <p><a class="btn btn-default" href="#" role="button">Learn more »</a></p>
+          <p><a class="btn btn-default" href="formats/" role="button">Learn more »</a></p>
         </div>
     </div>
-  
+    <br><br>
 
diff --git a/src/sphinx/installation.rst b/src/sphinx/installation.rst
deleted file mode 100644
index 3063a5d06..000000000
--- a/src/sphinx/installation.rst
+++ /dev/null
@@ -1,65 +0,0 @@
-.. _Installation:
-
-Installation
-===============
-
-The sbt-native-packager is a plugin. To use it, first create a ``project/plugins.sbt`` file with the following. 
-
-.. code-block:: scala
-
-  addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "0.8.0-M2")
-
-
-Also, each operating system requires its own tools for download.
-
-For the native packager keys add this to your build.sbt
-
-.. code-block:: scala
-
-  import com.typesafe.sbt.SbtNativePackager._
-  import NativePackagerKeys._
-
-Windows
--------
-
-Creating Windows ``msi`` packages requires the use of the Windows Installer Xml utilities.  These are available for download here: http://wix.sourceforge.net/downloadv35.html.  The plugin has only been tested with version 3.5+.
-
-
-RedHat/RPM-based linux distros
-------------------------------
-
-Creating ``rpm`` packages requires the use of the following command line tools:
-
-- ``rpmbuild``
-- ``rpm`` (optional)
-- ``rpmlint`` (optional)
-
-
-Debian-based linux distros
---------------------------
-
-Creating ``deb`` packages requires the use of the following command line tools:
-
-- ``dpkg-deb``
-- ``fakeroot``
-- ``chmod``
-- ``lintian`` (optional)
-
-Universal
----------
-
-Creating ``tgz`` or ``txz`` requires the use of the following command line tools:
-
-- ``gzip``
-- ``xz``
-- ``tar``
-
-Docker
-------
-
-Creating Docker images requires the use of the following command line tools:
-
-- ``docker``
-
-It is currently not possible to provide authentication for Docker repositories from within the build. The ``docker`` binary used by the build should already have been configured with the appropriate authentication details.
-See https://docs.docker.com/reference/commandline/cli/#login.
diff --git a/src/sphinx/DetailedTopics/custom.rst b/src/sphinx/topics/custom.rst
similarity index 100%
rename from src/sphinx/DetailedTopics/custom.rst
rename to src/sphinx/topics/custom.rst
diff --git a/src/sphinx/DetailedTopics/deployment.rst b/src/sphinx/topics/deployment.rst
similarity index 100%
rename from src/sphinx/DetailedTopics/deployment.rst
rename to src/sphinx/topics/deployment.rst
diff --git a/src/sphinx/documentation.rst b/src/sphinx/topics/documentation.rst
similarity index 100%
rename from src/sphinx/documentation.rst
rename to src/sphinx/topics/documentation.rst
diff --git a/src/sphinx/topics/index.rst b/src/sphinx/topics/index.rst
new file mode 100644
index 000000000..0b4649895
--- /dev/null
+++ b/src/sphinx/topics/index.rst
@@ -0,0 +1,13 @@
+Advanced Topics
+###############
+
+
+
+.. toctree::
+   :maxdepth: 2
+   
+   paths.rst
+   custom.rst
+   play.rst
+   deployment.rst
+   documentation.rst
diff --git a/src/sphinx/DetailedTopics/paths.rst b/src/sphinx/topics/paths.rst
similarity index 100%
rename from src/sphinx/DetailedTopics/paths.rst
rename to src/sphinx/topics/paths.rst
diff --git a/src/sphinx/DetailedTopics/play.rst b/src/sphinx/topics/play.rst
similarity index 83%
rename from src/sphinx/DetailedTopics/play.rst
rename to src/sphinx/topics/play.rst
index 30fdee127..cbe1511c7 100644
--- a/src/sphinx/DetailedTopics/play.rst
+++ b/src/sphinx/topics/play.rst
@@ -9,13 +9,13 @@ Build Configuration
 
 Depending on whether you want to package your application as a deb-package or
 as an rpm-package, you have to setup your build configuration accordingly.
-Please, refer to :doc:`Debian </DetailedTopics/debian>` and :doc:`Redhat </DetailedTopics/redhat>`
+Please, refer to :doc:`Debian </formats/debian>` and :doc:`Redhat </formats/rpm>`
 pages for additional information.
 
 Note that **Upstart** is not supported by all available operation systems and may not always work as expected.
 You can always fallback to the **SystemV** service manager instead.
 For more information on service managers please refer
-to :doc:`Getting Started With Servers </GettingStartedServers/index>` page.
+to :doc:`Getting Started With Servers </archetypes/java_server/index>` page.
 
 Application Configuration
 -------------------------
@@ -41,4 +41,4 @@ One way to provide this information is create ``src/templates/etc-default`` with
 This way you should either store your production configuration under ``${{path_to_app_name}}/conf/production.conf``
 or put it under ``/usr/share/${{app_name}}/conf/production.conf`` by hand or using some configuration management system.
 
-See :doc:`adding configuration </GettingStartedServers/AddingConfiguration>` for more information on `etc-default` template.
\ No newline at end of file
+See :doc:`adding configuration </archetypes/java_server/AddingConfiguration>` for more information on `etc-default` template.