brooklyn-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From m4rkmcke...@apache.org
Subject [05/50] [abbrv] brooklyn-docs git commit: Adapt doc to make compile with gitbook
Date Wed, 25 Oct 2017 21:04:50 GMT
Adapt doc to make compile with gitbook


Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/18c248c5
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/18c248c5
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/18c248c5

Branch: refs/heads/master
Commit: 18c248c53190ca06f91822caeacad2d62a97833b
Parents: 4af9a8b
Author: Thomas Bouron <thomas.bouron@cloudsoftcorp.com>
Authored: Fri Oct 6 10:19:02 2017 +0100
Committer: Thomas Bouron <thomas.bouron@cloudsoftcorp.com>
Committed: Mon Oct 16 14:55:34 2017 +0100

----------------------------------------------------------------------
 .gitignore                                      |   2 +
 SUMMARY.md                                      |   4 -
 book.json                                       |  42 ++++-
 guide/README.md                                 |   0
 guide/SUMMARY.md                                |  86 +++++++++
 guide/blueprints/ansible/index.md               |   2 +-
 guide/blueprints/blueprinting-tips.md           |   8 +-
 guide/blueprints/catalog/index.md               |   2 +-
 guide/blueprints/catalog/schema.md              |   2 +-
 .../chef/advanced-chef-integration.md           |   4 +-
 guide/blueprints/chef/creating-blueprints.md    |   4 +-
 guide/blueprints/chef/index.md                  |   2 +-
 guide/blueprints/clusters-and-policies.md       |  13 +-
 guide/blueprints/clusters.md                    |   4 +-
 guide/blueprints/configuring-vms.md             |   8 +-
 guide/blueprints/creating-yaml.md               |  22 ++-
 guide/blueprints/custom-entities.md             |  49 ++---
 guide/blueprints/effectors.md                   |  22 +--
 guide/blueprints/enrichers.md                   |  28 +--
 guide/blueprints/entity-configuration.md        |  62 +++----
 guide/blueprints/index.md                       |   2 +-
 guide/blueprints/java/archetype.md              |  28 +--
 guide/blueprints/java/bundle-dependencies.md    |  10 +-
 guide/blueprints/java/common-usage.md           |  24 +--
 guide/blueprints/java/defining-and-deploying.md |  39 ++--
 guide/blueprints/java/entities.md               |   4 +-
 guide/blueprints/java/entitlements.md           |  18 +-
 guide/blueprints/java/entity.md                 |  10 +-
 guide/blueprints/java/feeds.md                  |  24 +--
 guide/blueprints/java/index.md                  |   2 +-
 guide/blueprints/java/topology-dependencies.md  |   6 +-
 guide/blueprints/multiple-services.md           |  12 +-
 guide/blueprints/policies.md                    |  16 +-
 guide/blueprints/salt/index.md                  |   2 +-
 guide/blueprints/setting-locations.md           |  35 ++--
 guide/blueprints/test/index.md                  |   2 +-
 guide/blueprints/test/test-entities.md          |  34 ++--
 guide/blueprints/test/usage-examples.md         |  20 +--
 guide/blueprints/winrm/index.md                 |  10 +-
 guide/blueprints/yaml-reference.md              |   4 +-
 guide/concepts/dependent-configuration.md       |   4 +-
 guide/concepts/index.md                         |   2 +-
 guide/dev/env/ide/index.md                      |  12 +-
 guide/dev/env/maven-build.md                    |  12 +-
 guide/dev/index.md                              |   4 +-
 guide/dev/tips/debugging-remote-brooklyn.md     |  16 +-
 guide/dev/tips/index.md                         |   4 +-
 guide/dev/tips/logging.md                       |   8 +-
 guide/index.md                                  |  21 ---
 guide/list-children.html                        |   0
 guide/locations/_AWS.md                         |   2 +-
 guide/locations/_GCE.md                         |   2 +-
 guide/locations/_azure-ARM.md                   |   4 +-
 guide/locations/_azure-classic.md               |  20 +--
 guide/locations/_byon.md                        |  14 +-
 guide/locations/_clouds.md                      |  22 +--
 guide/locations/_cloudstack.md                  |   2 +-
 guide/locations/_ibm-softlayer.md               |   2 +-
 .../_inheritance-and-named-locations.md         |  12 +-
 guide/locations/_localhost.md                   |  14 +-
 guide/locations/_openstack.md                   |   2 +-
 guide/locations/_special-locations.md           |  18 +-
 guide/locations/_ssh-keys.md                    |  10 +-
 guide/locations/index.md                        | 180 ++++++++++++++++++-
 .../provisioned-machine-requirements.md         | 161 -----------------
 guide/misc/download.md                          | 110 +++++-------
 guide/misc/index.md                             |   2 +-
 guide/misc/release-notes.md                     |   4 +-
 guide/ops/cli/cli-ref-guide.md                  |  12 +-
 guide/ops/cli/cli-usage-guide.md                | 124 ++++++-------
 guide/ops/cli/index.md                          |  12 +-
 guide/ops/configuration/brooklyn_cfg.md         |  42 ++---
 guide/ops/configuration/cors.md                 |   4 +-
 guide/ops/configuration/https.md                |  12 +-
 guide/ops/externalized-configuration.md         |  72 ++++----
 guide/ops/gui/blueprints.md                     |  10 +-
 guide/ops/gui/index.md                          |   2 +-
 guide/ops/gui/policies.md                       |   4 +-
 guide/ops/gui/running.md                        |  10 +-
 .../high-availability-supplemental.md           |  32 ++--
 guide/ops/index.md                              |   2 +-
 guide/ops/logging.md                            |   8 +-
 guide/ops/persistence/index.md                  |   8 +-
 guide/ops/production-installation.md            |  42 +++--
 guide/ops/requirements.md                       |   8 +-
 guide/ops/server-cli-reference.md               |  12 +-
 guide/ops/starting-stopping-monitoring.md       |  10 +-
 guide/ops/troubleshooting/connectivity.md       |   2 +-
 guide/ops/troubleshooting/deployment.md         |  24 +--
 .../troubleshooting/detailed-support-report.md  |   6 +-
 .../going-deep-in-java-and-logs.md              |  82 ++++-----
 guide/ops/troubleshooting/increase-entropy.md   |  20 +--
 guide/ops/troubleshooting/index.md              |   2 +-
 guide/ops/troubleshooting/overview.md           |   2 +-
 guide/ops/troubleshooting/slow-unresponsive.md  |  72 ++++----
 guide/ops/upgrade.md                            |  28 +--
 guide/start/blueprints.md                       |  38 ++--
 guide/start/concept-quickstart.md               |   2 +-
 guide/start/index.md                            |   2 +-
 guide/start/managing.md                         | 100 +++++------
 guide/start/policies.md                         |  58 +++---
 guide/start/running.md                          | 118 ++++++------
 102 files changed, 1155 insertions(+), 1159 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/.gitignore
----------------------------------------------------------------------
diff --git a/.gitignore b/.gitignore
index 97a4608..49aa963 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,3 +35,5 @@ _pdf
 _config_local.yml
 .sass-cache
 style/js/catalog/items.js
+
+_book
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/SUMMARY.md
----------------------------------------------------------------------
diff --git a/SUMMARY.md b/SUMMARY.md
deleted file mode 100644
index 263112f..0000000
--- a/SUMMARY.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Summary
-
-* [Introduction](README.md)
-

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/book.json
----------------------------------------------------------------------
diff --git a/book.json b/book.json
index 316db54..36dda82 100644
--- a/book.json
+++ b/book.json
@@ -1,3 +1,43 @@
 {
-  "root": "./guide"
+  "root": "./guide",
+  "variables": {
+    "encoding": "utf-8",
+    "markdown": "kramdown",
+
+    "url_root": "http://0.0.0.0:4000",
+
+    "path": {
+      "style": "/style",
+      "guide": "/guide",
+      "website": "/website",
+      "v": "/v"
+    },
+
+    "dependency_mode": "local",
+    "dependency_urls": {
+      "bootstrap.css": "https://netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css",
+      "bootstrap.js": "https://netdna.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.min.js",
+      "jquery.js": "https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"
+    },
+
+    "root_menu_page": "/website/index.md",
+
+    "exclude": ["/Gemfile*", "/README.md"],
+
+    "sass": {
+      "sass_dir": "style/css"
+    },
+
+    "brooklyn-stable-version": "0.11.0",
+    "pdf-default-base-url": "http://brooklyn.apache.org",
+    "pdf-default-versioned-url-subpath": "/v/0.11.0",
+
+    "pdf-rewrite-prefixes": {
+      "/guide": "/v/0.11.0",
+      "/website": ""
+    },
+
+    "brooklyn-version": "0.13.0-SNAPSHOT",
+    "brooklyn-snapshot-git-branch": "master"
+  }
 }
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/README.md
----------------------------------------------------------------------
diff --git a/guide/README.md b/guide/README.md
new file mode 100644
index 0000000..e69de29

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/SUMMARY.md
----------------------------------------------------------------------
diff --git a/guide/SUMMARY.md b/guide/SUMMARY.md
new file mode 100644
index 0000000..9974807
--- /dev/null
+++ b/guide/SUMMARY.md
@@ -0,0 +1,86 @@
+# Apache Brooklyn documentation
+
+### User Guide
+
+* Getting Started
+  * [Running Apache Brooklyn](start/running.md)
+  * [Deploying Blueprints](start/blueprints.md)
+  * [Monitoring and Managing Applications](start/managing.md)
+  * [Policies](start/policies.md)
+  * [Concepts](start/concept-quickstart.md)
+* [Downloads](misc/download.md)
+* Brooklyn Concepts
+  * [Entities](concepts/entities.md)
+  * [Application, Parent and Membership](concepts/application-parent-membership.md)
+  * [Configuration, Sensors and Effectors](concepts/configuration-sensor-effectors.md)
+  * [Lifecycle and ManagementContext](concepts/lifecycle-managementcontext.md)
+  * [Dependent Configuration](concepts/dependent-configuration.md)
+  * [Location](concepts/location.md)
+  * [Policies](concepts/policies.md)
+  * [Execution](concepts/execution.md)
+  * [Stop/start/restart behaviour](concepts/stop-start-restart-behaviour.md)
+* [Writing Blueprints](blueprints/index.md)
+  * [Creating YAML Blueprint](blueprints/creating-yaml.md)
+  * [Entity Configuration](blueprints/entity-configuration.md)
+  * [Setting Locations](blueprints/setting-locations.md)
+  * [Configuring VMs](blueprints/configuring-vms.md)
+  * [Multiple Services and Dependency Injection](blueprints/multiple-services.md)
+  * [Custom Entities](blueprints/custom-entities.md)
+  * [Catalog](blueprints/catalog/index.md)
+  * [Clusters, Specs, and Composition](blueprints/clusters.md)
+  * [Enrichers](blueprints/enrichers.md)
+  * [Policies](blueprints/policies.md)
+  * [Effectors](blueprints/effectors.md)
+  * [Clusters and Policies](blueprints/clusters-and-policies.md)
+  * [Java Entities](blueprints/java/index.md)
+  * [Windows Blueprints](blueprints/winrm/index.md)
+  * [Testing YAML Blueprints](blueprints/test/index.md)
+  * [Ansible in YAML Blueprints](blueprints/ansible/index.md)
+  * [Chef in YAML Blueprints](blueprints/chef/index.md)
+  * [Salt in YAML Blueprints](blueprints/salt/index.md)
+  * [YAML Blueprint Advanced Example](blueprints/advanced-example.md)
+  * [Blueprinting Tips](blueprints/blueprinting-tips.md)
+  * [YAML Blueprint Reference](blueprint/yaml-reference.md)
+* [Deploying Blueprint](locations/index.md)
+  * [Provisioned Machine Requirements](locations/provisioned-machine-requirements.md)
+* Reference Guide
+  * [Production Installation](ops/production-installation.md)
+  * [Starting, Stopping and Monitoring](ops/starting-stopping-monitoring.md)
+  * [Server CLI Reference](ops/server-cli-reference.md)
+  * [Client CLI Reference](ops/cli/index.md)
+  * GUI Guide
+    * [Launching](ops/gui/running.md)
+    * [Deploying Blueprints](ops/gui/blueprints.md)
+    * [Monitoring and Managing Applications](ops/gui/managing.md)
+    * [Using Policies](ops/gui/policies.md)
+  * [REST API](ops/rest.md)
+  * [Brooklyn Configuration and Options](ops/configuration/index.md)
+  * [Persistence](ops/persistence/index.md)
+  * [High Availability](ops/high-availability/index.md)
+    * [Configuring HA - an example](ops/high-availability/high-availability-supplemental.md)
+  * [Logging](ops/logging.md)
+  * [Externalized Configuration](ops/externalized-configuration.md)
+  * [Requirements](ops/requirements.md)
+  * [Upgrade](ops/upgrade.md)
+  * [Security Guidelines](ops/security-guidelines.md)
+  * [Troubleshooting](ops/troubleshooting/index.md)
+* [Other 0.12.0 Resources](misc/index.md)
+
+### Developer Guide
+
+* [Get the Code](https://brooklyn.apache.org/developers/code/)
+* [Maven Build](dev/env/maven-build.md)
+* [IDE Setup](dev/env/ide/index.md)
+* [Code Structure](dev/code/structure.md)
+* [Tests](dev/code/tests.md)
+* [License Considerations](dev/code/licensing.md)
+* [Miscellaneous Tips and Tricks](dev/tips/index.md)
+* [Logging](dev/tips/logging.md)
+* [Brooklyn Remote Debugging](dev/tips/debugging-remote-brooklyn.md)
+* [GitHub](http://github.com/apache/brooklyn)
+* [Javadoc](https://brooklyn.apache.org/v/latest/misc/javadoc)
+
+----
+
+* [Versions](https://brooklyn.apache.org/meta/versions.html)
+* [Other Resources](https://brooklyn.apache.org/documentation/other-docs.html)
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/ansible/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/ansible/index.md b/guide/blueprints/ansible/index.md
index a2376d1..78ce33b 100644
--- a/guide/blueprints/ansible/index.md
+++ b/guide/blueprints/ansible/index.md
@@ -13,4 +13,4 @@ Comments on this support and suggestions for further development are welcome.
 
 This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
 
-{% include list-children.html %}
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/blueprinting-tips.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/blueprinting-tips.md b/guide/blueprints/blueprinting-tips.md
index 9712fef..40e33d7 100644
--- a/guide/blueprints/blueprinting-tips.md
+++ b/guide/blueprints/blueprinting-tips.md
@@ -37,11 +37,11 @@ Options for speeding up provisioning include those below.
 
 #### Deploying to Bring Your Own Nodes (BYON)
 
-A [BYON location]({{ site.path.guide }}/locations/#byon) can be defined, which avoids the time 
+A [BYON location]({{ book.path.guide }}/locations/#byon) can be defined, which avoids the time 
 required to provision VMs. This is fast, but has the downside that artifacts installed during a 
 previous run can interfere with subsequent runs.
 
-A variant of this is to [use Vagrant]({{ site.path.guide }}/start/running.html) (e.g. with VirtualBox) 
+A variant of this is to [use Vagrant]({{ book.path.guide }}/start/running.html) (e.g. with VirtualBox) 
 to create VMs on your local machine, and to use these as the target for a BYON location.
 
 These VMs should mirror the target environment as much as possible.
@@ -113,7 +113,7 @@ real thing.
 
 ## Writing Entity Tests
 
-Use the [test framework]({{ site.path.guide }}/blueprints/test/) to write test cases. This will make 
+Use the [test framework]({{ book.path.guide }}/blueprints/test/) to write test cases. This will make 
 automated (regression) testing easier, and will allow others to easily confirm that the entity 
 works in their environment.
 
@@ -180,4 +180,4 @@ below may also be of help:
 
 ALWAYS keep logs when there is an error.
 
-See the [Troubleshooting]({{ site.path.guide }}/ops/troubleshooting/) guide for more information. 
+See the [Troubleshooting]({{ book.path.guide }}/ops/troubleshooting/) guide for more information. 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/catalog/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/index.md b/guide/blueprints/catalog/index.md
index ed56483..d56be8f 100644
--- a/guide/blueprints/catalog/index.md
+++ b/guide/blueprints/catalog/index.md
@@ -18,4 +18,4 @@ folder by default and additional ones can be added through the web console or CL
 the catalog can be deployed directly, via the Brooklyn CLI or the web console, or referenced in 
 other blueprints using their `id`.
 
-{% include list-children.html %}
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/catalog/schema.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/schema.md b/guide/blueprints/catalog/schema.md
index 3edccf9..3291c03 100644
--- a/guide/blueprints/catalog/schema.md
+++ b/guide/blueprints/catalog/schema.md
@@ -223,7 +223,7 @@ The items this will add to the catalog are:
 
 #### Locations in the Catalog
 
-In addition to blueprints, locations can be added to the Apache Brooklyn catalog. The example below shows a location for the vagrant configuration used in the [getting started guide]({{ site.path.guide }}/start/blueprints.html), formatted as a catalog entry.
+In addition to blueprints, locations can be added to the Apache Brooklyn catalog. The example below shows a location for the vagrant configuration used in the [getting started guide]({{ book.path.guide }}/start/blueprints.html), formatted as a catalog entry.
 
 ~~~ yaml
 brooklyn.catalog:

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/chef/advanced-chef-integration.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/chef/advanced-chef-integration.md b/guide/blueprints/chef/advanced-chef-integration.md
index 1081cd3..0652d9b 100644
--- a/guide/blueprints/chef/advanced-chef-integration.md
+++ b/guide/blueprints/chef/advanced-chef-integration.md
@@ -30,7 +30,7 @@ indicated earlier.  If you'd like to work with us to implement these, please let
 
 A general schema for the supported YAML is below: 
 
-{% highlight yaml %}
+```yaml
 - type: chef:cookbook_name
   brooklyn.config:
     cookbook_urls:
@@ -40,7 +40,7 @@ A general schema for the supported YAML is below:
     launch_attributes: # map of arguments to set in the chef node
     service_name: cookbook_service
     pid_file: /var/run/cookbook.pid
-{% endhighlight %}
+```
 
 If you are interested in exploring the Java code for creating blueprints,
 start with the `TypedToyMySqlEntiyChef` class, which essentially does what this tutorial has shown;

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/chef/creating-blueprints.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/chef/creating-blueprints.md b/guide/blueprints/chef/creating-blueprints.md
index 8d30131..7d838a7 100644
--- a/guide/blueprints/chef/creating-blueprints.md
+++ b/guide/blueprints/chef/creating-blueprints.md
@@ -8,9 +8,7 @@ In a nutshell, a new Chef-based entity can be defined as a service by specifying
 `chef:cookbook_name` as the `service_type`, along with a collection of optional configuration.
 An illustrative example is below:
 
-{% highlight yaml %}
-{% readj example_yaml/mysql-chef-1.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/mysql-chef-1.yaml"
 
 *This works without any installation: try it now, copying-and-pasting to the Brooklyn console.
 (Don't forget to add your preferred `location: some-cloud` to the spec.)*  

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/chef/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/chef/index.md b/guide/blueprints/chef/index.md
index f0fa3d0..d183a5f 100644
--- a/guide/blueprints/chef/index.md
+++ b/guide/blueprints/chef/index.md
@@ -15,4 +15,4 @@ A plan for the full integration is online [here](https://docs.google.com/a/cloud
 
 This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
 
-{% include list-children.html %}
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/clusters-and-policies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/clusters-and-policies.md b/guide/blueprints/clusters-and-policies.md
index 0e9630f..0f3a740 100644
--- a/guide/blueprints/clusters-and-policies.md
+++ b/guide/blueprints/clusters-and-policies.md
@@ -12,9 +12,8 @@ But another blueprint, the `ControlledDynamicWebAppCluster`, does this for us.
 It takes the same `dynamiccluster.memberspec`, so we can build a fully functional elastic 3-tier
 deployment of our `hello-world-sql` application as follows:
 
-{% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-clustered-w-db.yaml"
+
 
 This sets up Nginx as the controller by default, but that can be configured
 using the `controllerSpec` key. 
@@ -25,9 +24,7 @@ JBoss is actually the default appserver in the `ControlledDynamicWebAppCluster`,
 so because `brooklyn.config` keys in Brooklyn are inherited by default,
 the same blueprint can be expressed more concisely as:
 
-{% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db-concise.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-clustered-w-db-concise.yaml"
  
 The other nicety supplied by the `ControlledDynamicWebAppCluster` blueprint is that
 it aggregates sensors from the appserver, so we have access to things like
@@ -37,9 +34,7 @@ We can set up our blueprint to do autoscaling based on requests per second
 (keeping it in the range 10..100, with a maximum of 5 appserver nodes)
 as follows: 
 
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-policy.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-w-policy.yaml"
 
 Use your favorite load-generation tool (`jmeter` is one good example) to send a huge
 volume of requests against the server and see the policies kick in to resize it.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/clusters.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/clusters.md b/guide/blueprints/clusters.md
index 4c1312c..11eb958 100644
--- a/guide/blueprints/clusters.md
+++ b/guide/blueprints/clusters.md
@@ -10,9 +10,7 @@ What if you want multiple machines?
 One way is just to repeat the `- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess` block,
 but there's another way which will keep your powder [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself):
 
-{% highlight yaml %}
-{% readj example_yaml/cluster-vm.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/cluster-vm.yaml"
 
 Here we've composed the previous blueprint introducing some new important concepts, the `DynamicCluster`
 the `$brooklyn` DSL, and the "entity-spec".  Let's unpack these. 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/configuring-vms.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/configuring-vms.md b/guide/blueprints/configuring-vms.md
index e7e7f47..07ab39a 100644
--- a/guide/blueprints/configuring-vms.md
+++ b/guide/blueprints/configuring-vms.md
@@ -7,9 +7,7 @@ categories: [use, guide, defining-applications]
 
 Another simple blueprint will just create a VM which you can use, without any software installed upon it:
 
-{% highlight yaml %}
-{% readj example_yaml/simple-vm.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-vm.yaml"
 
 
 *We've omitted the `location` section here and in many of the examples below;
@@ -18,7 +16,7 @@ ignored if deploying to `localhost` or `byon` fixed-IP machines.*
 
 This will create a VM with the specified parameters in your choice of cloud.
 In the GUI (and in the REST API), the entity is called "VM",
-and the hostname and IP address(es) are reported as [sensors]({{ site.path.guide }}/concepts/entities.html).
+and the hostname and IP address(es) are reported as [sensors]({{ book.path.guide }}/concepts/entities.html).
 There are many more `provisioning.properties` supported here,
 including:
 
@@ -28,4 +26,4 @@ including:
 * `machineCreateAttempts` (for dodgy clouds, and they nearly all fail occasionally!) 
 * and things like `imageId` and `userMetadata` and disk and networking options (e.g. `autoAssignFloatingIp` for private clouds)
 
-For more information, see [Operations: Locations]({{ site.path.guide }}/locations/index.html).
+For more information, see [Operations: Locations]({{ book.path.guide }}/locations/index.html).

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/creating-yaml.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/creating-yaml.md b/guide/blueprints/creating-yaml.md
index 6f91784..3798c0b 100644
--- a/guide/blueprints/creating-yaml.md
+++ b/guide/blueprints/creating-yaml.md
@@ -18,26 +18,24 @@ it's easy to add new extensions using your favorite JVM language.)
 
 Here's a very simple YAML blueprint plan, to explain the structure:
 
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-appserver.yaml"
 
 * The `name` is just for the benefit of us humans.
 
 * The `location` specifies where this should be deployed.
-  If you've [set up passwordless localhost SSH access]({{ site.path.guide }}/locations/#localhost) 
+  If you've [set up passwordless localhost SSH access]({{ book.path.guide }}/locations/#localhost) 
   you can use `localhost` as above, but if not, just wait ten seconds for the next example.
   
 * The `services` block takes a list of the typed services we want to deploy.
   This is the meat of the blueprint plan, as you'll see below.
 
 Finally, the clipboard in the top-right corner of the example plan box above (hover your cursor over the box)  lets you easily copy-and-paste into the web-console:
-simply [download and launch]({{ site.path.guide }}/start/running.html) Brooklyn,
+simply [download and launch]({{ book.path.guide }}/start/running.html) Brooklyn,
 then in the "Create Application" dialog at the web console
 (usually [http://127.0.0.1:8081/](http://127.0.0.1:8081/), paste the copied YAML into the "Yaml" tab of the dialog and press "Finish". 
 There are several other ways to deploy, including `curl` and via the command-line,
 and you can configure users, https, persistence, and more, 
-as described [in the ops guide]({{ site.path.guide }}/ops/).
+as described [in the ops guide]({{ book.path.guide }}/ops/).
 
 [![Web Console](web-console-yaml-700.png "YAML via Web Console")](web-console-yaml.png)
 
@@ -54,25 +52,25 @@ TODO building up children entities
 
 Topics to explore next on the topic of YAML blueprints are:
 
-{% include list-children.html %}
+
 
 Plenty of examples of blueprints exist in the Brooklyn codebase,
-so another starting point is to [`git clone`]({{ site.path.website }}/developers/code/index.html) it
+so another starting point is to [`git clone`]({{ book.path.website }}/developers/code/index.html) it
 and search for `*.yaml` files therein.
 
 Brooklyn lived as a Java framework for many years before we felt confident
 to make a declarative front-end, so you can do pretty much anything you want to
 by dropping to the JVM. For more information on Java:
 
-* start with a [Maven archetype]({{site.path.guide}}/blueprints/java/archetype.html)
-* see all [Brooklyn Java guide]({{site.path.guide}}/blueprints/java/) topics
+* start with a [Maven archetype]({{book.path.guide}}/blueprints/java/archetype.html)
+* see all [Brooklyn Java guide]({{book.path.guide}}/blueprints/java/) topics
 * look at test cases in the [codebase](https://github.com/apache/brooklyn)
 
 <!-- 
 TODO
-* review some [examples]({{site.path.guide}}/use/examples/index.html)
+* review some [examples]({{book.path.guide}}/use/examples/index.html)
 -->
 
 You can also come talk to us, on IRC (#brooklyncentral on Freenode) or
-any of the usual [hailing frequencies]({{site.path.website}}/community/),
+any of the usual [hailing frequencies]({{book.path.website}}/community/),
 as these documents are a work in progress.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/custom-entities.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/custom-entities.md b/guide/blueprints/custom-entities.md
index efd03ba..5f77faf 100644
--- a/guide/blueprints/custom-entities.md
+++ b/guide/blueprints/custom-entities.md
@@ -19,9 +19,7 @@ including `bash` and Chef.
 The following blueprint shows how a simple script can be embedded in the YAML
 (the `|` character is special YAML which makes it easier to insert multi-line text):
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat.yaml"
 
 This starts a simple `nc` listener on port 4321 which will respond `hello` to the first
 session which connects to it. Test it by running `telnet localhost 4321`
@@ -49,9 +47,7 @@ So if we create a file `/tmp/netcat-server.tgz` containing just `start.sh` in th
 which contains the line `echo hello | nc -l 4321`, 
 we can instead write our example as: 
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-file.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-file.yaml"
 
 
 #### Determining Successful Launch
@@ -69,14 +65,11 @@ the `nc` process exits afterwards, causing Brooklyn to set the entity to an `ON_
 (You can also test this with a `killall nc`).
 
 There are other options for determining health: you can set `checkRunning.command` and `stop.command` instead,
-as documented on the javadoc and config keys of the 
-{% include java_link.html class_name="VanillaSoftwareProcess" package_path="org/apache/brooklyn/entity/software/base" project_subpath="software/base" %} class, 
-and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`. For example:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-more-commands.yaml %}
-{% endhighlight %}
+as documented on the javadoc and config keys of the
+[org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/entity/software/base/VanillaSoftwareProcess.html)
+class, and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`. For example:
 
+!CODEFILE "example_yaml/vanilla-bash-netcat-more-commands.yaml"
 
 #### Periodic Health Check
 
@@ -96,9 +89,7 @@ We can tell Brooklyn to open this port explicitly by specifying `inboundPorts: [
 however a more idiomatic way is to specify a config ending with `.port`,
 such as:
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-port.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-port.yaml"
 
 The regex for ports to be opened can be configured using
 the config `inboundPorts.configRegex` (which has `.*\.port` as the default value).
@@ -126,9 +117,7 @@ However config keys which are *not* declared on the type *must* be declared in t
 Blueprint scripts can be parametrised through environment variables, making them reusable in different use-cases.
 Define the variables in the `env` block and then reference them using the standard bash notation:
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-env.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-env.yaml"
 
 Non-string objects in the `env` map will be serialized to JSON before passing them to the script.
 
@@ -138,9 +127,7 @@ Non-string objects in the `env` map will be serialized to JSON before passing th
 We can define config keys to be presented to the user 
 using the `brooklyn.parameters` block:
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-port-parameter.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-port-parameter.yaml"
 
 The example above will allow a user to specify a message to send back
 and the port where netcat will listen.
@@ -166,9 +153,7 @@ This gives us quite a bit more power in writing our blueprint:
 The *Catalog* tab allows you to add blueprints which you can refer to in other blueprints.
 In that tab, click *+* then *YAML*, and enter the following:
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-catalog.bom %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-catalog.bom"
 
 This is the same example as in the previous section, wrapped according to the catalog YAML requirements,
 with one new block added defining an enricher. An enricher creates a new sensor from other values;
@@ -178,9 +163,7 @@ with the sensor values.
 With this added to the catalog, we can reference the type `netcat-example` when we deploy an application.
 Return to the *Home* or *Applications* tab, click *+*, and submit this YAML blueprint:
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-reference.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-reference.yaml"
 
 This extends the previous blueprint which we registered in the catalog,
 meaning that we don't need to include it each time.
@@ -190,9 +173,7 @@ More importantly, we can package it for others to consume -- or take items other
 We can go further and use this to deploy a cluster,
 this time giving a custom port as well as a custom message: 
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-cluster.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-cluster.yaml"
 
 In either of the above examples, if you explore the tree in the *Applications* view
 and look at the *Summary* tab of any of the server instances, you'll now see the URL where netcat is running.
@@ -206,9 +187,7 @@ and if you haven't yet experimented with `resize` on the cluster you might want
 Besides detecting this failure, Brooklyn policies can be added to the YAML to take appropriate 
 action. A simple recovery here might just to automatically restart the process:
 
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-restarter.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-restarter.yaml"
 
 Autonomic management in Brooklyn often follows the principle that complex behaviours emerge
 from composing simple policies.
@@ -285,7 +264,7 @@ command over ssh every 5 seconds. This can be very CPU intensive when there are
 is to disable the ssh-polling (by setting `sshMonitoring.enabled: false`) and to configure a different 
 health-check.
 
-See documentation on the [Entity's error status]({{ site.path.guide }}/ops/troubleshooting/overview.html#entitys-error-status)
+See documentation on the [Entity's error status]({{ book.path.guide }}/ops/troubleshooting/overview.html#entitys-error-status)
 for how Brooklyn models an entity's health.
 
 In the snippet below, we'll define a new health-check sensor (via http polling), and will automatically add this

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/effectors.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/effectors.md b/guide/blueprints/effectors.md
index 41eb645..e56bcd0 100644
--- a/guide/blueprints/effectors.md
+++ b/guide/blueprints/effectors.md
@@ -4,7 +4,7 @@ layout: website-normal
 ---
 
 Effectors perform an operation of some kind, carried out by a Brooklyn Entity.
-They can be manually invoked or triggered by a [Policy]({{ site.path.guide }}/blueprints/policies.html).
+They can be manually invoked or triggered by a [Policy]({{ book.path.guide }}/blueprints/policies.html).
 
 Common uses of an effector include the following:
 
@@ -36,7 +36,7 @@ There are a number of additional configuration keys available for the `SSHComman
 
 Here is a simple example of an `SshCommandEffector` definition:
 
-{% highlight yaml %}
+```yaml
   brooklyn.initializers:
   - type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
     brooklyn.config:
@@ -48,7 +48,7 @@ Here is a simple example of an `SshCommandEffector` definition:
         message:
           description: The string to pass to netcat
           defaultValue: hi netcat
-{% endhighlight %}
+```
 
 See [`here`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/effector/ssh/SshCommandEffector.html) for more details.
 
@@ -74,7 +74,7 @@ There are a number of additional configuration keys available for the `HTTPComma
 
 When a the header `HttpHeaders.CONTENT_TYPE` is equals to *application/x-www-form-urlencoded* and the `httpPayload` is a `map`, the payload is transformed into a single string using `URLEncoded`.
 
-{% highlight yaml %}
+```yaml
 brooklyn.initializers:
 - type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
   brooklyn.config:
@@ -94,7 +94,7 @@ brooklyn.initializers:
       $.access_token: access.token
     headers:
       Content-Type: "application/x-www-form-urlencoded"
-{% endhighlight %}
+```
 
 See [`here`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/effector/http/HttpCommandEffector.html) for more details.
 
@@ -102,7 +102,7 @@ See [`here`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brookl
 
 An `Effector` to add a child blueprint to an entity.
 
-{% highlight yaml %}
+```yaml
 brooklyn.initializers:
 - type: org.apache.brooklyn.core.effector.AddChildrenEffector
   brooklyn.config:
@@ -129,7 +129,7 @@ brooklyn.initializers:
             version: 0.1.0
             url: classpath:/brooklyn/osgi/brooklyn-test-osgi-entities.jar
     auto_start: true
-{% endhighlight %}
+```
 
 One of the config keys `BLUEPRINT_YAML` (containing a YAML blueprint (map or string)) or `BLUEPRINT_TYPE` (containing a string referring to a catalog type) should be supplied, but not both.
 
@@ -148,7 +148,7 @@ Writing an effector is straightforward.
 Simply extend [`AddEffector`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/effector/AddEffector.html),
 providing an implementation for `newEffectorBuilder` and adding a constructor that consumes the builder or override an existing effector.
 
-{% highlight java %}
+```java
 
  public MyEffector(ConfigBag params) {
     super(newEffectorBuilder(params).build());
@@ -159,11 +159,11 @@ public static EffectorBuilder<String> newEffectorBuilder(ConfigBag params) {
     eff.impl(new Body(eff.buildAbstract(), params));
     return eff;
 }
-{% endhighlight %}
+```
 
 and supply an `EffectorBody` similar to:
 
-{% highlight java %}
+```java
 
 protected static class Body extends EffectorBody<String> {
     ...
@@ -173,7 +173,7 @@ protected static class Body extends EffectorBody<String> {
      ...
     }
 }
-{% endhighlight %}
+```
 
 ### Best Practice
 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/enrichers.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/enrichers.md b/guide/blueprints/enrichers.md
index 6ef1247..2d7cb01 100644
--- a/guide/blueprints/enrichers.md
+++ b/guide/blueprints/enrichers.md
@@ -14,9 +14,7 @@ See below for documentation of the stock enrichers available in Apache Brooklyn.
 
 Takes a source sensor and modifies it in some way before publishing the result in a new sensor. See below an example using `$brooklyn:formatString`.
 
-{% highlight yaml %}
-{% readj example_yaml/enricher-transformer.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-transformer.yaml"
 
 #### Propagator
 
@@ -26,9 +24,7 @@ Use propagator to duplicate one sensor as another, giving the supplied sensor ma
 The other use of Propagator is where you specify a producer (using `$brooklyn:entity(...)` as below)
 from which to take sensors; in that mode you can specify `propagate` as a list of sensors whose names are unchanged, instead of (or in addition to) this map.
 
-{% highlight yaml %}
-{% readj example_yaml/enricher-propagator.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-propagator.yaml"
 
 #### Custom Aggregating
 
@@ -36,9 +32,7 @@ from which to take sensors; in that mode you can specify `propagate` as a list o
 
 Aggregates multiple sensor values (usually across a tier, esp. a cluster) and performs a supplied aggregation method to them to return an aggregate figure, e.g. sum, mean, median, etc.
 
-{% highlight yaml %}
-{% readj example_yaml/enricher-aggregator.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-aggregator.yaml"
 
 There are a number of additional configuration keys available for the Aggregators:
 
@@ -54,9 +48,7 @@ There are a number of additional configuration keys available for the Aggregator
 
 Joins a sensor whose output is a list into a single item joined by a separator.
 
-{% highlight yaml %}
-{% readj example_yaml/enricher-joiner.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-joiner.yaml"
 
 There are a number of additional configuration keys available for the joiner:
 
@@ -81,9 +73,7 @@ Converts an absolute sensor into a delta sensor (i.e. the difference between the
 
 Converts absolute sensor values into a difference over time. The `enricher.delta.period` indicates the measurement interval.
 
-{% highlight yaml %}
-{% readj example_yaml/enricher-time-weighted-delta.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-time-weighted-delta.yaml"
 
 ####	Rolling Mean
 
@@ -130,16 +120,14 @@ For example, if we consider the Transfomer from above, suppose that `enricher.so
 is actually a sensor on a different entity called `load.balancer`. In this case, we would need to supply an
 `enricher.producer` value.
 
-{% highlight yaml %}
-{% readj example_yaml/enricher-transformer.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-transformer.yaml"
 
 It is important to note that the value supplied to `enricher.producer` must be immediately resolvable. While it would be valid
 DSL syntax to write:
 
-{% highlight yaml %}
+```yaml
 enricher.producer: brooklyn:entity($brooklyn:attributeWhenReady("load.balancer.entity"))
-{% endhighlight %}
+```
 
 (assuming the `load.balancer.entity` sensor returns a Brooklyn entity), this will not function properly because `enricher.producer`
 will unsuccessfully attempt to get the supplied entity immediately.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/entity-configuration.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/entity-configuration.md b/guide/blueprints/entity-configuration.md
index 25827ad..b956708 100644
--- a/guide/blueprints/entity-configuration.md
+++ b/guide/blueprints/entity-configuration.md
@@ -19,14 +19,14 @@ and also it does not work in all contexts such as for an enricher's configuratio
 
 A simple example is shown below:
 
-{% highlight yaml %}
+```yaml
 services:
 - type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
   brooklyn.config:
     webapp.enabledProtocols: http
     http.port: 9080
     wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-webapp/0.9.0/brooklyn-example-hello-world-webapp-0.9.0.war
-{% endhighlight %}
+```
 
 If no config value is supplied, the default for that config key will be used. For example, 
 `http.port` would default to 8080 if not explicitly supplied.
@@ -44,7 +44,7 @@ blueprint (i.e. inside the `brooklyn.config` block).
 It can also explicitly declare config keys, using the `brooklyn.parameters` block. The example 
 below illustrates the principle:
 
-{% highlight yaml %}
+```yaml
 brooklyn.catalog:
   items:
   - id: entity-config-example
@@ -64,19 +64,19 @@ brooklyn.catalog:
           echo "My example launch command: $MESSAGE"
         checkRunning.command: |
           echo "My example checkRunning command: $MESSAGE"
-{% endhighlight %}
+```
 
 Once added to the catalog, it can be used with the simple blueprint below (substituting the location
 of your choice). Because no configuration has been overridden, this will use the default value
 for `custom.message`, and will use the given values for `launch.command` and `checkRunning.command`:
 
-{% highlight yaml %}
+```yaml
 location: aws-ec2:us-east-1
 services:
 - type: entity-config-example
-{% endhighlight %}
+```
 
-For details of how to write and add catalog items, see [Catalog]({{ site.path.guide }}/blueprints/catalog/). 
+For details of how to write and add catalog items, see [Catalog]({{ book.path.guide }}/blueprints/catalog/). 
 
 
 #### Config Key Constraints
@@ -91,7 +91,7 @@ can be any of:
 
 This is illustrated in the example below:
 
-{% highlight yaml %}
+```yaml
 brooklyn.catalog:
   items:
   - id: entity-constraint-example
@@ -121,18 +121,18 @@ brooklyn.catalog:
             factoryMethod.name: lessThan
             factoryMethod.args:
             - 256.0
-{% endhighlight %}
+```
 
 An example usage of this toy example, once added to the catalog, is shown below:
 
-{% highlight yaml %}
+```yaml
 services:
 - type: entity-constraint-example
   brooklyn.config:
     compulsoryExample: foo
     addressExample: 1.1.1.1
     numberExample: 2.0
-{% endhighlight %}
+```
 
 
 ### Inheriting Configuration
@@ -167,7 +167,7 @@ consider the `entity-config-example` added to the catalog in the section
 [Configuration in a Catalog Item](#configuration-in-a-catalog-item).
 We can override these values. If not overridden, then the existing values from the super-type will be used:
 
-{% highlight yaml %}
+```yaml
 location: aws-ec2:us-east-1
 services:
 - type: entity-config-example
@@ -175,7 +175,7 @@ services:
     custom.message: Goodbye
     launch.command: |
       echo "Sub-type launch command: $MESSAGE"
-{% endhighlight %}
+```
 
 
 
@@ -193,7 +193,7 @@ Configuration passed to an entity is inherited by all child entities, unless exp
 In the example below, the `wars.root` config key is inherited by all TomcatServer entities created
 under the cluster, so they will use that war:
 
-{% highlight yaml %}
+```yaml
 services:
 - type: org.apache.brooklyn.entity.group.DynamicCluster
   brooklyn.config:
@@ -201,7 +201,7 @@ services:
     dynamiccluster.memberspec:
       $brooklyn:entitySpec:
         type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
-{% endhighlight %}
+```
 
 In the above example, it would be better to have specified the `wars.root` configuration in the 
 `TomcatServer` entity spec, rather than at the top level. This would make it clearer for the reader
@@ -236,7 +236,7 @@ it retrievies the value of `exampleConfig` which is the DSL expression, and eval
 context of the parent entity that declares it. Therefore `$brooklyn:config("ownConfig")` returns 
 the parent's `ownConfig` value, and the final result for `refExampleConfig` is set to "parentValue":
 
-{% highlight yaml %}
+```yaml
 services:
 - type: org.apache.brooklyn.entity.stock.BasicApplication
   brooklyn.config:
@@ -248,7 +248,7 @@ services:
     brooklyn.config:
       ownConfig: childValue
       refExampleConfig: $brooklyn:config("exampleConfig")
-{% endhighlight %}
+```
 
 _However, the web-console also shows other misleading (incorrect!) config values for the child 
 entity. It shows the inherited config value of `exampleConfig` as "childValue" (because the
@@ -282,7 +282,7 @@ the section [Configuration in a Catalog Item](#configuration-in-a-catalog-item))
 The environment variables will include the `MESSAGE` 
 set in the super-type and the `MESSAGE2` set here:
 
-{% highlight yaml %}
+```yaml
 location: aws-ec2:us-east-1
 services:
 - type: entity-config-example
@@ -291,7 +291,7 @@ services:
       MESSAGE2: Goodbye
     launch.command: |
       echo "Different example launch command: $MESSAGE and $MESSAGE2"
-{% endhighlight %}
+```
 
 To explicitly remove a value from the super-type's map (rather than adding to it), a blank entry
 can be defined. 
@@ -311,7 +311,7 @@ In the example below, the VM will be provisioned with minimum 2G ram and minimum
 also use the merged template options value of 
 `{placementGroup: myPlacementGroup, securityGroupIds: sg-000c3a6a}`:
 
-{% highlight yaml %}
+```yaml
 location:
   aws-ec2:us-east-1:
     minRam: 2G
@@ -324,14 +324,14 @@ services:
       minCores: 2
       templateOptions:
         securityGroupIds: sg-000c3a6a
-{% endhighlight %}
+```
 
 The merging of `templateOptions` is shallow (i.e. maps within the `templateOptions` are not merged). 
 In the example below, the `userMetadata` value within `templateOptions` will be overridden by the 
 entity's value, rather than the maps being merged; the value used when provisioning will be 
 `{key2: val2}`:
 
-{% highlight yaml %}
+```yaml
 location:
   aws-ec2:us-east-1:
     templateOptions:
@@ -343,7 +343,7 @@ services:
     provisioning.properties:
       userMetadata:
         key2: val2
-{% endhighlight %}
+```
 
 
 #### Re-inherited Versus not Re-inherited
@@ -368,7 +368,7 @@ and is co-located on the same VM as Tomcat. We don't want the Tomcat's configura
 entity might re-execute the Tomcat's install command! Instead, the `install.command` config is
 "consumed" by the Tomcat instance and is not re-inherited:
 
-{% highlight yaml %}
+```yaml
 services:
 - type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
   brooklyn.config:
@@ -378,14 +378,14 @@ services:
     brooklyn.config:
       logstash.elasticsearch.host: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets")
 ...
-{% endhighlight %}
+```
 
 "Not re-inherited" differs from "never inherited". The example below illustrates the difference, 
 though this use is discouraged (it is mostly for backwards compatibility). The `post.install.command`
 is not consumed by the `BasicApplication`, so will be inherited by the `Tomcat8Server` which will
 consume it. The config value will therefore not be inherited by the `logstash-child`.
 
-{% highlight yaml %}
+```yaml
 services:
 - type: org.apache.brooklyn.entity.stock.BasicApplication
   brooklyn.config:
@@ -399,7 +399,7 @@ services:
       brooklyn.config:
         logstash.elasticsearch.host: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets")
 ...
-{% endhighlight %}
+```
 
 
 #### Never Inherited
@@ -470,7 +470,7 @@ Below is a (contrived!) example of inheriting the `example.map` config key. When
 in a blueprint, the entity's config will be merged with that defined in the super-type, and the 
 parent entity's value will never be inherited:
 
-{% highlight yaml %}
+```yaml
 brooklyn.catalog:
   items:
   - id: entity-config-inheritance-example
@@ -489,7 +489,7 @@ brooklyn.catalog:
       brooklyn.config:
         example.map:
           MESSAGE: Hello
-{% endhighlight %}
+```
 
 The blueprints below demonstrate the various permutations for setting configuration for the
 config `example.map`. This can be inspected by looking at the entity's config. The config
@@ -499,7 +499,7 @@ config from the parent is not inherited because there is an explicit inheritance
 so it just has the value `{MESSAGE: "Hello"}`; in app4 again the parent's config is ignored,
 with the super-type and entity's config being merged to give  `{MESSAGE: "Hello", MESSAGE_IN_CHILD: "InChild"}`.
 
-{% highlight yaml %}
+```yaml
 location: aws-ec2:us-east-1
 services:
 - type: org.apache.brooklyn.entity.stock.BasicApplication
@@ -533,7 +533,7 @@ services:
     brooklyn.config:
       example.map:
         MESSAGE_IN_CHILD: InChild
-{% endhighlight %}
+```
 
 A limitations of `inheritance.parent` is when inheriting values from parent and grandparent 
 entities: a value specified on the parent will override (rather than be merged with) the

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/index.md b/guide/blueprints/index.md
index 01ab184..260fc2d 100644
--- a/guide/blueprints/index.md
+++ b/guide/blueprints/index.md
@@ -26,4 +26,4 @@ children:
 ---
 
 
-{% include list-children.html %}
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/archetype.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/archetype.md b/guide/blueprints/java/archetype.md
index f9acac8..8c112ad 100644
--- a/guide/blueprints/java/archetype.md
+++ b/guide/blueprints/java/archetype.md
@@ -14,9 +14,9 @@ developing a new Java entity, and generating the OSGi bundle for it.
 #### Generating the Project
 
 The archetype can be used interactively, by running:
-{% highlight bash %}
+```bash
 $ mvn archetype:generate
-{% endhighlight %}
+```
 
 The user will be prompted for the archetype to use (i.e. group "org.apache.brooklyn" 
 and artifact "brooklyn-archetype-quickstart"), as well as options for the project 
@@ -25,8 +25,8 @@ to be created.
 Alternatively, all options can be supplied at the command line. For example, 
 if creating a project named "autobrick" for "com.acme":
 
-{% highlight bash %}
-$ BROOKLYN_VERSION={{ site.brooklyn-version }}
+```bash
+$ BROOKLYN_VERSION={{ book.brooklyn-version }}
 $ mvn archetype:generate \
 	-DarchetypeGroupId=org.apache.brooklyn \
 	-DarchetypeArtifactId=brooklyn-archetype-quickstart \
@@ -36,7 +36,7 @@ $ mvn archetype:generate \
 	-Dversion=0.1.0-SNAPSHOT \
 	-DpackageName=com.acme.autobrick \
 	-DinteractiveMode=false
-{% endhighlight %}
+```
 
 This will create a directory with the artifact name (e.g. "autobrick" in the example above).
 Note that if run from a directory containing a pom, it will also modify that pom to add this as 
@@ -52,16 +52,16 @@ The `README.md` file within the project gives further guidance.
 
 To build, run the commands:
 
-{% highlight bash %}
+```bash
 $ cd autobrick
 $ mvn clean install
-{% endhighlight %}
+```
 
 
 #### Adding to the Catalog
 
 The build will produce an OSGi bundle in `target/autobrick-0.1.0-SNAPSHOT.jar`, suitable for 
-use in the [Brooklyn catalog]({{ site.path.guide }}/blueprints/catalog/) (using `brooklyn.libraries`).
+use in the [Brooklyn catalog]({{ book.path.guide }}/blueprints/catalog/) (using `brooklyn.libraries`).
 
 To use this in your Brooklyn catalog you will first have to copy the target jar to a suitable location. 
 For developing/testing purposes storing on the local filesystem is fine. 
@@ -72,7 +72,7 @@ The project comes with a `catalog.bom` file, located in `src/main/resources`.
 Modify this file by adding a 'brooklyn.libraries' statement to the bom pointing to the jar. 
 For example:
 
-{% highlight yaml %}
+```yaml
 brooklyn.catalog:
     brooklyn.libraries:
     - file:///path/to/jar/autobrick-0.1.0-SNAPSHOT.jar
@@ -82,13 +82,13 @@ brooklyn.catalog:
     - id: com.acme.autobrick.MySample
       item:
         type: com.acme.autobrick.MySample
-{% endhighlight %}
+```
 
 The command below will use the CLI to add this to the catalog of a running Brooklyn instance:
 
-{% highlight bash %}
+```bash
     br catalog add catalog.bom
-{% endhighlight %}
+```
 
 After running that command, the OSGi bundle will have been added to the OSGi container, and the
 entity will have been added to your catalog. It can then be used in the same way as regular Brooklyn 
@@ -96,10 +96,10 @@ entities.
 
 For example, you can use the blueprint:
 
-{% highlight yaml %}
+```yaml
 services:
 - type: com.acme.autobrick.MySample
-{% endhighlight %}
+```
 
 
 ### Testing Entities

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/bundle-dependencies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/bundle-dependencies.md b/guide/blueprints/java/bundle-dependencies.md
index 0f07fb6..a8e4732 100644
--- a/guide/blueprints/java/bundle-dependencies.md
+++ b/guide/blueprints/java/bundle-dependencies.md
@@ -28,7 +28,7 @@ is a convenient way of building OSGi bundles.
 
 #### OSGi Bundles Declared in Catalog Items  
 
-Within a [catalog item]({{ site.path.guide}}/blueprints/catalog/), a list of URLs can be supplied under
+Within a [catalog item]({{ book.path.guide}}/blueprints/catalog/), a list of URLs can be supplied under
 `brooklyn.libraries`. Each URL should point to an OSGi bundle. This list should include the OSGi 
 bundle that has the Java code for your blueprint, and also the OSGi bundles that it depends
 on (including all transitive dependencies).
@@ -37,8 +37,8 @@ It is vital that these jars are built correctly as OSGi bundles, and that all tr
 dependencies are included. The bundles will be added to Karaf in the order given, so a bundle's
 dependencies should be listed before the bundle(s) that depend on them.
 
-In the [GistGenerator example]({{ site.path.guide}}/blueprints/java/defining-and-deploying.html), the 
-[catalog.bom file]({{ site.path.guide}}/blueprints/java/gist_generator/gist_generator.bom) included
+In the [GistGenerator example]({{ book.path.guide}}/blueprints/java/defining-and-deploying.html), the 
+[catalog.bom file]({{ book.path.guide}}/blueprints/java/gist_generator/gist_generator.bom) included
 the URL of the dependency `org.eclipse.egit.github.core`. It also (before that line) included
 its transitive dependency, which is a specific version of `gson`.
 
@@ -64,7 +64,7 @@ using `./bin/client`, and add the bundles and features as desired.
 
 Examples of some useful commands are shown below:
 
-{% highlight bash %}
+```bash
 karaf@amp> bundle:install -s http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.egit.github.core/2.1.5_1/org.apache.servicemix.bundles.egit.github.core-2.1.5_1.jar
 Bundle ID: 316
 
@@ -75,7 +75,7 @@ karaf@amp> bundle:headers org.apache.servicemix.bundles.egit.github.core
 ...
 
 karaf@amp> bundle:uninstall org.apache.servicemix.bundles.egit.github.core
-{% endhighlight %}
+```
 
 
 ##### Karaf Deploy Folder

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/common-usage.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/common-usage.md b/guide/blueprints/java/common-usage.md
index 2c9d91b..3410a37 100644
--- a/guide/blueprints/java/common-usage.md
+++ b/guide/blueprints/java/common-usage.md
@@ -33,11 +33,11 @@ Configuration keys are typically defined as static named fields on the Entity in
 define the configuration values that can be passed to the entity during construction. For
 example:
 
-{% highlight java %}
+```java
 public static final ConfigKey<String> ROOT_WAR = new ConfigKeys.newStringConfigKey(
         "wars.root",
         "WAR file to deploy as the ROOT, as URL (supporting file: and classpath: prefixes)");
-{% endhighlight %}
+```
 
 If supplying a default value, it is important that this be immutable. Otherwise, it risks users
 of the blueprint modifying the default value, which would affect blueprints that are subsequently 
@@ -62,11 +62,11 @@ port starting from 8081 will be used.
 Sensors are typically defined as static named fields on the Entity interface. These define 
 the events published by the entity, which interested parties can subscribe to. For example:
 
-{% highlight java %}
+```java
 AttributeSensor<String> MANAGEMENT_URL = Sensors.newStringSensor(
         "crate.managementUri",
         "The address at which the Crate server listens");
-{% endhighlight %}
+```
 
 
 ### Declaring Effectors
@@ -79,23 +79,23 @@ be defined. Examples of each are given below.
 A method on the entity interface can be annotated to indicate it is an effector, and to provide
 metadata about the effector and its parameters.
 
-{% highlight java %}
+```java
 @org.apache.brooklyn.core.annotation.Effector(description="Retrieve a Gist")
 public String getGist(@EffectorParam(name="id", description="Gist id") String id);
-{% endhighlight %}
+```
 
 
 #### Static Field Effector Declaration
 
 A static field can be defined on the entity to define an effector, giving metadata about that effector.
 
-{% highlight java %}
+```java
 public static final Effector<String> EXECUTE_SCRIPT = Effectors.effector(String.class, "executeScript")
         .description("invokes a script")
         .parameter(ExecuteScriptEffectorBody.SCRIPT)
         .impl(new ExecuteScriptEffectorBody())
         .build();
-{% endhighlight %}
+```
 
 In this example, the implementation of the effector is an instance of `ExecuteScriptEffectorBody`. 
 This implements `EffectorBody`. It will be invoked whenever the effector is called.
@@ -107,7 +107,7 @@ An effector can be added to an entity dynamically - either as part of the entity
 or as separate initialization code. This allows the implementation of the effector to be shared
 amongst multiple entities, without sub-classing. For example:
 
-{% highlight java %}
+```java
 Effector<Void> GET_GIST = Effectors.effector(Void.class, "createGist")
         .description("Create a Gist")
         .parameter(String.class, "id", "Gist id")
@@ -125,7 +125,7 @@ public static void CreateGistEffectorBody implements EffectorBody<Void>() {
 public void init() {
     getMutableEntityType().addEffector(CREATE_GIST, new CreateGistEffectorBody());
 }
-{% endhighlight %}
+```
 
 
 ### Effector Invocation
@@ -172,12 +172,12 @@ marked as done until its queued sub-tasks are complete.
 When creating tasks, the `TaskBuilder` can be used to create simple tasks or to create compound tasks
 whose sub-tasks are to be executed either sequentially or in parallel. For example:
 
-{% highlight java %}
+```java
 TaskBuilder.<Integer>builder()
         .displayName("stdout-example")
         .body(new Callable<Integer>() { public Integer call() { System.out.println("example"; } })
         .build();
-{% endhighlight %}
+```
 
 There are also builder and factory utilities for common types of operation, such as executing SSH 
 commands using `SshTasks`.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/defining-and-deploying.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/defining-and-deploying.md b/guide/blueprints/java/defining-and-deploying.md
index 11a2889..744dead 100644
--- a/guide/blueprints/java/defining-and-deploying.md
+++ b/guide/blueprints/java/defining-and-deploying.md
@@ -14,7 +14,7 @@ with an effector to create new gists.
 ## Project Setup
 
 Follow the instructions to create a new Java project using the [archetype](archetype.html), and
-import it into your [favorite IDE]({{ site.path.guide }}/dev/env/ide/). This example assumes you 
+import it into your [favorite IDE]({{ book.path.guide }}/dev/env/ide/). This example assumes you 
 used the groupId `com.acme` and artifact id `autobrick`.
 
 First ensure you can build this project at the command line, using `mvn clean install`.
@@ -27,21 +27,19 @@ a dependency. Add the following to your `pom.xml` inside the `<dependencies>` se
 (see [Maven](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html) 
 for more details):
 
-{% highlight xml %}
+```xml
 <dependency>
   <groupId>org.eclipse.mylyn.github</groupId>
   <artifactId>org.eclipse.egit.github.core</artifactId>
   <version>2.1.5</version>
 </dependency>
-{% endhighlight %}
+```
 
 Create a new Java interface, `GistGenerator`, to describe the entity's interface (i.e. the 
 configuration options, sensors, and effectors). The code below assumes you have created this
 in the package `com.acme` for `src/main/java`.
 
-{% highlight java %}
-{% readj gist_generator/GistGenerator.java %}
-{% endhighlight %}
+!CODEFILE "gist_generator/GistGenerator.java"
 
 To describe each part of this:
 
@@ -63,9 +61,7 @@ discussed in the section [Dynamically Added Effectors](common-usage.html#dynamic
 
 Next lets add the implementation. Create a new Java class named `GistGeneratorImpl`.
 
-{% highlight java %}
-{% readj gist_generator/GistGeneratorImpl.java %}
-{% endhighlight %}
+!CODEFILE "gist_generator/GistGeneratorImpl.java"
 
 To describe each part of this:
 
@@ -109,9 +105,7 @@ We will create a similar Java-based test for this blueprint. Create a new Java c
 You will need to substitute the github access token you generated in the previous section for
 the placeholder text `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`.
 
-{% highlight java %}
-{% readj gist_generator/GistGeneratorTest.java %}
-{% endhighlight %}
+!CODEFILE "gist_generator/GistGeneratorTest.java"
 
 Similarly, we can write a test that uses the `GistGenerator` from a YAML blueprint. 
 Create a new Java class named `GistGeneratorYamlTest` in the package `com.acme`, 
@@ -119,13 +113,10 @@ inside `src/test/java`.
 
 Again you will need to substitute the github access token you generated in the previous section for
 the placeholder text `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`. See the section on 
-[externalised configuration]({{ site.path.guide }}/ops/externalized-configuration.html) 
+[externalised configuration]({{ book.path.guide }}/ops/externalized-configuration.html) 
 for how to store these credentials more securely. 
 
-{% highlight java %}
-{% readj gist_generator/GistGeneratorYamlTest.java %}
-{% endhighlight %}
-
+!CODEFILE "gist_generator/GistGeneratorYamlTest.java"
 
 ## Building the OSGi Bundle
 
@@ -145,20 +136,18 @@ Similar to the `sample.bom` entity that ships with the archetype, we will define
 to add our `GistGenerator` to the catalog. Substitute the URL below for your own newly built 
 artifact (which will be in the `target` sub-directory after running `mvn clean install`).
 
-{% highlight yaml %}
-{% readj gist_generator/gist_generator.bom %}
-{% endhighlight %}
+!CODEFILE "gist_generator/gist_generator.bom"
 
-See [Handling Bundle Dependencies]({{ site.path.guide}}/blueprints/java/bundle-dependencies.html)
+See [Handling Bundle Dependencies]({{ book.path.guide}}/blueprints/java/bundle-dependencies.html)
 for a description of the `brooklyn.libraries` used above, and for other alternative approaches.
 
 The command below will use the `br` CLI to add this to the catalog of a running Brooklyn instance.
 Substitute the credentials, URL and port for those of your server.
 
-{% highlight bash %}
+```bash
 $ br login https://127.0.0.1:8443 admin pa55w0rd
 $ br catalog add gist_generator.bom
-{% endhighlight %}
+```
 
 
 ## Using the blueprint
@@ -173,5 +162,5 @@ The YAML blueprint below shows an example usage of this blueprint:
 
 Note the type name matches the id defined in the `.bom` file.
 
-You can now call the effector by any of the standard means - [web console]({{ site.path.guide }}/ops/gui/), 
-[REST api]({{ site.path.guide }}/ops/rest.html), or [Client CLI]({{ site.path.guide }}/ops/cli/).
+You can now call the effector by any of the standard means - [web console]({{ book.path.guide }}/ops/gui/), 
+[REST api]({{ book.path.guide }}/ops/rest.html), or [Client CLI]({{ book.path.guide }}/ops/cli/).

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/entities.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/entities.md b/guide/blueprints/java/entities.md
index 1e2623d..5dc23e4 100644
--- a/guide/blueprints/java/entities.md
+++ b/guide/blueprints/java/entities.md
@@ -74,7 +74,7 @@ Sensors at base entities are often retrieved by feeds which poll the entity's co
 The ``SoftwareProcess`` provides a good example; by subclassing it and overriding the ``connectSensors()`` method
 you could wire some example sensors using the following: 
 
-{% highlight java %}
+```java
 public void connectSensors() {
 	super.connectSensors()
 	
@@ -95,7 +95,7 @@ protected void disconnectSensors() {
     super.disconnectSensors();
     if (httpFeed != null) httpFeed.stop();
 }
-{% endhighlight %}
+```
 
 In this example (a simplified version of ``JBoss7Server``), the url returns metrics in JSON. 
 We report the entity as up if we get back an http response code of 200, or down if any other response code or exception.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/entitlements.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/entitlements.md b/guide/blueprints/java/entitlements.md
index 91d8dac..f0c67d7 100644
--- a/guide/blueprints/java/entitlements.md
+++ b/guide/blueprints/java/entitlements.md
@@ -8,9 +8,11 @@ essentially permissions.
 
 Any entitlement scheme can be implemented by supplying a class which implements one method on one class:
 
-    public interface EntitlementManager {
-      public <T> boolean isEntitled(@Nullable EntitlementContext context, @Nonnull EntitlementClass<T> entitlementClass, @Nullable T entitlementClassArgument);
-    }
+```java
+public interface EntitlementManager {
+    public <T> boolean isEntitled(@Nullable EntitlementContext context, @Nonnull EntitlementClass<T> entitlementClass, @Nullable T entitlementClassArgument);
+}
+```
 
 This answers the question who is allowed do what to whom, looking at the following fields:
 
@@ -24,19 +26,21 @@ This answers the question who is allowed do what to whom, looking at the followi
 
 To set a custom entitlements manager to apply across the board, simply use:
 
-    brooklyn.entitlements.global=org.apache.brooklyn.core.mgmt.entitlement.AcmeEntitlementManager
+```properties
+brooklyn.entitlements.global=org.apache.brooklyn.core.mgmt.entitlement.AcmeEntitlementManager
+```
 
 The example above refers to a sample manager which is included in the test JARs of Brooklyn,
-which you can see [here]({{ site.brooklyn.url.git }}/core/src/test/java/org/apache/brooklyn/core/mgmt/entitlement/AcmeEntitlementManagerTest.java),
+which you can see [here]({{ book.brooklyn.url.git }}/core/src/test/java/org/apache/brooklyn/core/mgmt/entitlement/AcmeEntitlementManagerTest.java),
 and include in your project by adding the core tests JAR to your `dropins` folder.
 
 There are some entitlements schemes which exist out of the box, so for a simpler setup,
-see [Operations: Entitlements]({{ site.path.guide }}/ops/configuration/brooklyn_cfg.html#entitlements). 
+see [Operations: Entitlements]({{ book.path.guide }}/ops/configuration/brooklyn_cfg.html#entitlements). 
 
 There are also more complex schemes which some users have developed, including LDAP extensions 
 which re-use the LDAP authorization support in Brooklyn, 
 allowing permissions objects to be declared in LDAP leveraging regular expressions.
 For more information on this, ask on IRC or the mailing list,
 and see 
-{% include java_link.html class_name="EntitlementManager" package_path="org/apache/brooklyn/api/mgmt/entitlement" project_subpath="api" %}.
 
+[EntitlementManager](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/api/mgmt/entitlement/EntitlementManager.html).

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/entity.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/entity.md b/guide/blueprints/java/entity.md
index 8b05d9c..72d41c4 100644
--- a/guide/blueprints/java/entity.md
+++ b/guide/blueprints/java/entity.md
@@ -13,9 +13,9 @@ There are several ways to write a new entity:
   scripts.
 * For composite entities, use YAML to compose exiting types of entities (potentially overwriting
   parts of their configuration), and wire them together.
-* Use **[Chef recipes]({{site.path.guide}}/blueprints/chef)**.
-* Use **[Salt formulas]({{site.path.guide}}/blueprints/salt)**.
-* Use **[Ansible playbooks]({{site.path.guide}}/blueprints/ansible)**.
+* Use **[Chef recipes]({{book.path.guide}}/blueprints/chef)**.
+* Use **[Salt formulas]({{book.path.guide}}/blueprints/salt)**.
+* Use **[Ansible playbooks]({{book.path.guide}}/blueprints/ansible)**.
 * Write pure-java, extending existing base-classes. For example, the `GistGenerator` 
   [example](defining-and-deploying.html). These can use utilities such as `HttpTool` and 
   `BashCommands`.
@@ -99,6 +99,6 @@ hierarchy; it is suggested to avoid these, looking at the ones below instead):
 
 You might also find the following helpful:
 
-* **[Entity Design Tips]({{site.path.guide}}/dev/tips/index.html#EntityDesign)**
-* The **[User Guide]({{site.path.guide}})**
+* **[Entity Design Tips]({{book.path.guide}}/dev/tips/index.html#EntityDesign)**
+* The **[User Guide]({{book.path.guide}})**
 * The **[Mailing List](https://mail-archives.apache.org/mod_mbox/brooklyn-dev/)**

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/feeds.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/feeds.md b/guide/blueprints/java/feeds.md
index 4c151de..e904db8 100644
--- a/guide/blueprints/java/feeds.md
+++ b/guide/blueprints/java/feeds.md
@@ -37,7 +37,7 @@ important that the entity's `rebind()` method recreates the feed.
 
 An `HttpFeed` polls over http(s). An example is shown below:
 
-{% highlight java %}
+```java
 private HttpFeed feed;
 
 @Override
@@ -61,14 +61,14 @@ protected void disconnectSensors() {
   super.disconnectSensors();
   if (feed != null) feed.stop();
 }
-{% endhighlight %}
+```
 
 
 ##### SSH Feed
 
 An SSH feed executes a command over ssh periodically. An example is shown below:
 
-{% highlight java %}
+```java
 private AbstractCommandFeed feed;
 
 @Override
@@ -91,13 +91,13 @@ protected void disconnectSensors() {
   super.disconnectSensors();
   if (feed != null) feed.stop();
 }
-{% endhighlight %}
+```
 
 ##### WinRm CMD Feed
 
 A WinRM feed executes a windows command over winrm periodically. An example is shown below:
 
-{% highlight java %}
+```java
 private AbstractCommandFeed feed;
 
 //@Override
@@ -118,7 +118,7 @@ protected void disconnectSensors() {
   super.disconnectSensors();
   if (feed != null) feed.stop();
 }
-{% endhighlight %}
+```
 
 ##### Windows Performance Counter Feed
 
@@ -131,7 +131,7 @@ This feed uses WinRM to invoke the windows utility <tt>typeperf</tt> to query fo
 of performance counters, by name. The values are extracted from the response, and published to the
 entity's sensors. An example is shown below:
 
-{% highlight java %}
+```java
 private WindowsPerformanceCounterFeed feed;
 
 @Override
@@ -147,7 +147,7 @@ protected void disconnectSensors() {
   super.disconnectSensors();
   if (feed != null) feed.stop();
 }
-{% endhighlight %}
+```
 
 
 ##### JMX Feed
@@ -160,7 +160,7 @@ or it can be explicitly supplied.
 
 An example is shown below:
 
-{% highlight java %}
+```java
 private JmxFeed feed;
 
 @Override
@@ -184,7 +184,7 @@ protected void disconnectSensors() {
   super.disconnectSensors();
   if (feed != null) feed.stop();
 }
-{% endhighlight %}
+```
 
 
 
@@ -196,7 +196,7 @@ an in-line anonymous inner classes).
 
 An example is shown below:
 
-{% highlight java %}
+```java
 public static class ErrorCountRetriever implements Callable<Integer> {
   private final Entity entity;
   
@@ -230,4 +230,4 @@ protected void disconnectSensors() {
   super.disconnectSensors();
   if (feed != null) feed.stop();
 }
-{% endhighlight %}
+```

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/index.md b/guide/blueprints/java/index.md
index 1cd025e..71943a5 100644
--- a/guide/blueprints/java/index.md
+++ b/guide/blueprints/java/index.md
@@ -19,7 +19,7 @@ children:
 Java blueprints are powerful, but also rather more difficult to write than YAML.
 Advanced Java skills are required.
 
-{% include list-children.html %}
+
 
 The main uses of Java-based blueprints are:
 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/topology-dependencies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/topology-dependencies.md b/guide/blueprints/java/topology-dependencies.md
index 93bbce3..29aa8a0 100644
--- a/guide/blueprints/java/topology-dependencies.md
+++ b/guide/blueprints/java/topology-dependencies.md
@@ -11,12 +11,10 @@ recommended.
 
 The example below creates a three tier web service, composed of an Nginx load-balancer, 
 a cluster of Tomcat app-servers, and a MySQL database. It is similar to the [YAML policies
-example]({{ site.path.guide }}/start/policies.html), but also includes the MySQL database
+example]({{ book.path.guide }}/start/policies.html), but also includes the MySQL database
 to demonstrate the use of dependent configuration.
 
-{% highlight java %}
-{% readj java_app/ExampleWebApp.java %}
-{% endhighlight %}
+!CODEFILE "java_app/ExampleWebApp.java"
 
 To describe each part of this:
 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/multiple-services.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/multiple-services.md b/guide/blueprints/multiple-services.md
index 955e2bd..b9baa94 100644
--- a/guide/blueprints/multiple-services.md
+++ b/guide/blueprints/multiple-services.md
@@ -12,9 +12,7 @@ services can be configured, composed, and combined.
 
 We'll begin by using more key-value pairs to configure the JBoss server to run a real app:
 
-{% highlight yaml %}
-{% readj example_yaml/appserver-configured.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-configured.yaml"
 
 (As before, you'll need to add the `location` info; `localhost` will work for these and subsequent examples.)
 
@@ -32,9 +30,7 @@ If you explored the `hello-world-sql` application we just deployed,
 you'll have noticed it tries to access a database.
 And it fails, because we have not set one up.  Let's do that now:
 
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-db.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-w-db.yaml"
 
 Here there are a few things going on:
 
@@ -80,9 +76,7 @@ in superclasses and are portable across multiple implementations.
 
 Here's an example deploying the same application but with different flavors of the components:
 
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-db-other-flavor.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-w-db-other-flavor.yaml"
 
 By changing two lines we've switched from JBoss and MySQL to Tomcat and MariaDB.
 

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/policies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/policies.md b/guide/blueprints/policies.md
index ff8d1f1..d5510d2 100644
--- a/guide/blueprints/policies.md
+++ b/guide/blueprints/policies.md
@@ -39,7 +39,7 @@ An AutoScaler policy can take any sensor as a metric, have its watermarks tuned
 
 e.g. if the average request per second across a cluster of Tomcat servers goes over the high watermark, it will resize the cluster to bring the average back to within the watermarks.
 
-{% highlight yaml %}
+```yaml
 brooklyn.policies:
 - type: org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
   brooklyn.config:
@@ -50,7 +50,7 @@ brooklyn.policies:
     resizeDownStabilizationDelay: 1m
     maxPoolSize: 3
 
-{% endhighlight %}
+```
 
 
 #### ServiceRestarter Policy
@@ -62,12 +62,12 @@ Attaches to a SoftwareProcess or to anything Startable which emits `ha.entityFai
 If there is a subsequent failure within a configurable time interval or if the restart fails, 
 this gives up and emits `ha.entityFailed.restart` for other policies to act upon or for manual intervention.
 
-{% highlight yaml %}
+```yaml
 brooklyn.policies:
 - type: org.apache.brooklyn.policy.ha.ServiceRestarter
   brooklyn.config:
     failOnRecurringFailuresInThisDuration: 5m
-{% endhighlight %}
+```
 
 Typically this is used in conjunction with the FailureDetector enricher to emit the trigger sensor.
 The [introduction to policies](../start/policies.html) shows a worked 
@@ -204,24 +204,24 @@ Writing a policy is straightforward.
 Simply extend [``AbstractPolicy``](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/policy/AbstractPolicy.html),
 overriding the [``setEntity``](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/objs/AbstractEntityAdjunct.html#setEntity-org.apache.brooklyn.api.entity.EntityLocal-) method to supply any subscriptions desired:
 
-{% highlight java %}
+```java
     @Override
     public void setEntity(EntityLocal entity) {
         super.setEntity(entity)
         subscribe(entity, TARGET_SENSOR, this)
     }
-{% endhighlight %}
+```
 
 and supply the computation and/or activity desired whenever that event occurs:
 
-{% highlight java %}
+```java
     @Override
     public void onEvent(SensorEvent<Integer> event) {
         int val = event.getValue()
         if (val % 2 == 1)
             entity.sayYoureOdd();
     }
-{% endhighlight %}
+```
 
 
 You'll want to do more complicated things, no doubt,

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/salt/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/salt/index.md b/guide/blueprints/salt/index.md
index 265e07f..b639602 100644
--- a/guide/blueprints/salt/index.md
+++ b/guide/blueprints/salt/index.md
@@ -13,4 +13,4 @@ Comments on this support and suggestions for further development are welcome.
 
 This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
 
-{% include list-children.html %}
+

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/setting-locations.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/setting-locations.md b/guide/blueprints/setting-locations.md
index 91efc5f..ea9138e 100644
--- a/guide/blueprints/setting-locations.md
+++ b/guide/blueprints/setting-locations.md
@@ -5,20 +5,16 @@ toc: ../guide_toc.json
 categories: [use, guide, defining-applications]
 ---
 
-{% include fields.md %}
-
 Brooklyn supports a very wide range of target locations. 
 With deep integration to [Apache jclouds](https://jclouds.apache.org), most well-known clouds 
-and cloud platforms are supported. See the [Locations guide]({{ site.path.guide }}/locations/) 
+and cloud platforms are supported. See the [Locations guide]({{ book.path.guide }}/locations/) 
 for details and more examples.
 
 ### Cloud Example
 
 The following example is for Amazon EC2:
 
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-appserver-with-location.yaml"
 
 (You'll need to replace the `identity` and `credential` with the 
 "Access Key ID" and "Secret Access Key" for your account,
@@ -36,10 +32,7 @@ You can also specify pre-existing servers to use -- "bring-your-own-nodes".
 The example below shows a pool of machines that will be used by the entities within the 
 application.
 
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-byon.yaml %}
-{% endhighlight %}
-
+!CODEFILE "example_yaml/simple-appserver-with-location-byon.yaml"
 
 ### Single Line and Multi Line Locations
 
@@ -48,11 +41,11 @@ configuration option per line (recommended for all but the simplest locations).
 
 For example, the two examples below are equivalent:
 
-{% highlight yaml %}
+```yaml
 location: byon(name="my loc",hosts="1.2.3.4",user="bob",privateKeyFile="~/.ssh/bob_id_rsa")
-{% endhighlight %}
+```
 
-{% highlight yaml %}
+```yaml
 location:
   byon:
     name: "my loc"
@@ -60,7 +53,7 @@ location:
     - "1.2.3.4"
     user: "bob"
     privateKeyFile: "~/.ssh/bob_id_rsa"
-{% endhighlight %}
+```
 
 
 ### Specific Locations for Specific Entities
@@ -71,9 +64,7 @@ well as, defining the location at the top-level of the blueprint).
 The example below will deploy Tomcat and JBoss App Server to different Bring Your Own Nodes
 locations:
 
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-per-entity.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-appserver-with-location-per-entity.yaml"
 
 The rules for precedence when defining a location for an entity are:
 
@@ -95,9 +86,7 @@ In the example below, it will create a cluster of app-servers in each location.
 used for each `DynamicCluster`; all app-servers inside that cluster will obtain a machine from
 that given location.
 
-{% highlight yaml %}
-{% readj example_yaml/fabric-with-multiple-locations.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/fabric-with-multiple-locations.yaml"
 
 The entity hierarchy at runtime will have a `DynamicFabric` with two children, each of type 
 `DynamicCluster` (each running in different locations), each of which initially has three 
@@ -113,14 +102,14 @@ The examples above have given all the location details within the application bl
 It is also possible (and indeed preferred) to add the location definitions to the catalog
 so that they can be referenced by name in any blueprint.
 
-For more information see the [Operations: Catalog]({{ site.path.guide }}/blueprints/catalog/) section of 
+For more information see the [Operations: Catalog]({{ book.path.guide }}/blueprints/catalog/) section of 
 the User Guide.
 
 
 ### Externalized Configuration
 
 For simplicity, the examples above have included the cloud credentials. For a production system, 
-it is strongly recommended to use [Externalized Configuration]({{ site.path.guide }}/ops/externalized-configuration.html)
+it is strongly recommended to use [Externalized Configuration]({{ book.path.guide }}/ops/externalized-configuration.html)
 to retrieve the credentials from a secure credentials store, such as [Vault](https://www.vaultproject.io).
 
 
@@ -128,5 +117,5 @@ to retrieve the credentials from a secure credentials store, such as [Vault](htt
 
 An entity that represents a "software process" can use the configuration option 
 `provisioning.properties` to augment the location's configuration. For more information, see
-[Entity Configuration]({{ site.path.guide }}/blueprints/entity-configuration.html#entity-provisioningproperties-overriding-and-merging)
+[Entity Configuration]({{ book.path.guide }}/blueprints/entity-configuration.html#entity-provisioningproperties-overriding-and-merging)
 details.

http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/test/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/test/index.md b/guide/blueprints/test/index.md
index 8b10f01..06862c4 100644
--- a/guide/blueprints/test/index.md
+++ b/guide/blueprints/test/index.md
@@ -30,4 +30,4 @@ TargetableTestComponents can be chained together, with the target being inherite
 
 The following sections provide details on each test entity along with examples of their use.
 
-{% include list-children.html %}
+


Mime
View raw message