This is an automated email from the ASF dual-hosted git repository.

heneveld pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/brooklyn-docs.git

commit 7f8efba0c63b694704019243bfc8eb1f7ad877fb
Author: Alex Heneveld <[email protected]>
AuthorDate: Thu Jul 22 23:56:03 2021 +0100

    use simpler `read` in most places
    
    in the few places `readj` was truly needed, invoke it as `read_jekyll`
---
 _extra/big_examples/global-web-fabric/index.md       |  2 +-
 _extra/big_examples/index.md                         |  2 +-
 _extra/big_examples/messaging/index.md               |  2 +-
 .../nosql-cassandra/cassandra.include.md             |  2 +-
 _extra/big_examples/nosql-cassandra/index.md         |  2 +-
 _extra/big_examples/simple-web-cluster.md            |  2 +-
 _extra/big_examples/webcluster.md                    |  2 +-
 _extra/big_examples/webcluster/index.md              |  2 +-
 _extra/big_examples/webcluster/webcluster.include.md |  2 +-
 _extra/simple_java_examples/examples.md              |  6 +++---
 guide/blueprints/chef/creating-blueprints.md         |  2 +-
 guide/blueprints/clusters-and-policies.md            |  6 +++---
 guide/blueprints/clusters.md                         |  2 +-
 guide/blueprints/configuring-vms.md                  |  2 +-
 guide/blueprints/creating-yaml.md                    |  2 +-
 guide/blueprints/custom-entities.md                  | 20 ++++++++++----------
 guide/blueprints/enrichers.md                        | 12 ++++++------
 guide/blueprints/java/defining-and-deploying.md      | 10 +++++-----
 guide/blueprints/java/topology-dependencies.md       |  2 +-
 guide/blueprints/multiple-services.md                |  6 +++---
 guide/blueprints/setting-locations.md                |  8 ++++----
 guide/blueprints/test/test-entities.md               | 16 ++++++++--------
 guide/blueprints/test/usage-examples.md              |  6 +++---
 guide/dev/env/ide/index.md                           |  2 +-
 guide/ops/gui/blueprints.md                          |  2 +-
 guide/ops/gui/policies.md                            |  2 +-
 website/learnmore/features/index.md                  |  8 ++++----
 27 files changed, 66 insertions(+), 66 deletions(-)

diff --git a/_extra/big_examples/global-web-fabric/index.md 
b/_extra/big_examples/global-web-fabric/index.md
index 73fe5d9..1be3780 100644
--- a/_extra/big_examples/global-web-fabric/index.md
+++ b/_extra/big_examples/global-web-fabric/index.md
@@ -12,7 +12,7 @@ It can combine with the [Simple Web Cluster](../webcluster) 
example
 or the [Portable Cloud 
Foundry](https://github.com/cloudsoft/brooklyn-cloudfoundry) example,
 but does not assume knowledge of either of these.
 
-{% readj ../before-begin.include.md %}
+{% read ../before-begin.include.md %}
 
 Now, go to this particular example's directory:
 
diff --git a/_extra/big_examples/index.md b/_extra/big_examples/index.md
index ce3f624..0f2ec47 100644
--- a/_extra/big_examples/index.md
+++ b/_extra/big_examples/index.md
@@ -6,7 +6,7 @@ toc: /guide/toc.json
 
 We currently have the following examples on the site:
 
-{% capture ltocs %}{% readj toc.json %}{% endcapture %}
+{% capture ltocs %}{% read_jekyll toc.json %}{% endcapture %}
 {% jsonball ltoc from var ltocs %}
 
 {% for x in ltoc %}
diff --git a/_extra/big_examples/messaging/index.md 
b/_extra/big_examples/messaging/index.md
index ec0089c..a8d8806 100644
--- a/_extra/big_examples/messaging/index.md
+++ b/_extra/big_examples/messaging/index.md
@@ -10,7 +10,7 @@ these examples we will use the Apache 
[Qpid](http://qpid.apache.org/)
 Java AMQP message broker and clients using the
 [JMS](http://docs.oracle.com/javaee/6/tutorial/doc/bnceh.html) API.
 
-{% readj ../before-begin.include.md %}
+{% read ../before-begin.include.md %}
 
 Now, go to this particular example's directory:
 
diff --git a/_extra/big_examples/nosql-cassandra/cassandra.include.md 
b/_extra/big_examples/nosql-cassandra/cassandra.include.md
index 924a980..93d29c3 100644
--- a/_extra/big_examples/nosql-cassandra/cassandra.include.md
+++ b/_extra/big_examples/nosql-cassandra/cassandra.include.md
@@ -1,5 +1,5 @@
       
-{% readj ../before-begin.include.md %}
+{% read ../before-begin.include.md %}
 
 ## Simple Cassandra Cluster
 
diff --git a/_extra/big_examples/nosql-cassandra/index.md 
b/_extra/big_examples/nosql-cassandra/index.md
index 7e7948e..fa14a12 100644
--- a/_extra/big_examples/nosql-cassandra/index.md
+++ b/_extra/big_examples/nosql-cassandra/index.md
@@ -4,4 +4,4 @@ title: Cassandra Clusters
 toc: /guide/toc.json
 ---
 
-{% readj cassandra.include.md %}
+{% read cassandra.include.md %}
diff --git a/_extra/big_examples/simple-web-cluster.md 
b/_extra/big_examples/simple-web-cluster.md
index 2b08a37..94f0ea7 100644
--- a/_extra/big_examples/simple-web-cluster.md
+++ b/_extra/big_examples/simple-web-cluster.md
@@ -6,4 +6,4 @@ toc: /guide/toc.json
 
 <!-- file kept to preserve old links; remove when link not used -->
 
-{% readj webcluster/webcluster.include.md %}
+{% read webcluster/webcluster.include.md %}
diff --git a/_extra/big_examples/webcluster.md 
b/_extra/big_examples/webcluster.md
index 2b08a37..94f0ea7 100644
--- a/_extra/big_examples/webcluster.md
+++ b/_extra/big_examples/webcluster.md
@@ -6,4 +6,4 @@ toc: /guide/toc.json
 
 <!-- file kept to preserve old links; remove when link not used -->
 
-{% readj webcluster/webcluster.include.md %}
+{% read webcluster/webcluster.include.md %}
diff --git a/_extra/big_examples/webcluster/index.md 
b/_extra/big_examples/webcluster/index.md
index 99c6b36..67fbad9 100644
--- a/_extra/big_examples/webcluster/index.md
+++ b/_extra/big_examples/webcluster/index.md
@@ -4,4 +4,4 @@ title: Elastic Web Cluster
 toc: /guide/toc.json
 ---
 
-{% readj webcluster.include.md %}
+{% read webcluster.include.md %}
diff --git a/_extra/big_examples/webcluster/webcluster.include.md 
b/_extra/big_examples/webcluster/webcluster.include.md
index 42140c1..c160c9a 100644
--- a/_extra/big_examples/webcluster/webcluster.include.md
+++ b/_extra/big_examples/webcluster/webcluster.include.md
@@ -1,5 +1,5 @@
       
-{% readj ../before-begin.include.md %}
+{% read ../before-begin.include.md %}
 
 ## Simple Web Server
 
diff --git a/_extra/simple_java_examples/examples.md 
b/_extra/simple_java_examples/examples.md
index 4c0d479..72278b2 100644
--- a/_extra/simple_java_examples/examples.md
+++ b/_extra/simple_java_examples/examples.md
@@ -52,7 +52,7 @@ It is then started in a localhost location (other locations 
are shown in the nex
 The Tomcat's configuration indicates that the given WAR should be deployed to 
the Tomcat server when it is started.
 
 {% highlight java %}
-{% readj example_files/tomcat_simple.java %}
+{% read example_files/tomcat_simple.java %}
 {% endhighlight %}
 
 The ``wars`` config is also supported (with config keys ``ROOT_WAR`` and 
``NAMED_WARS`` the long-hand syntax);
@@ -78,7 +78,7 @@ brooklyn launch --app TomcatServerApp --location 
aws-ec2:eu-west-1
 The code below starts a Tomcat cluster along with an Nginx instance, where 
each Tomcat server in the cluster is registered with the Nginx instance.
 
 {% highlight java %}
-{% readj example_files/tomcat_nginx.java %}
+{% read example_files/tomcat_nginx.java %}
 {% endhighlight %}
 
 This creates a cluster that of Tomcat servers, along with an Nginx instance. 
The ``NginxController`` instance
@@ -106,7 +106,7 @@ The ``ControlledDynamicWebAppCluster`` entity used above 
can also be used with a
 a web-cluster in each location.
 
 {% highlight java %}
-{% readj example_files/tomcat_multi-location.java %}
+{% read example_files/tomcat_multi-location.java %}
 {% endhighlight %}
 
 
diff --git a/guide/blueprints/chef/creating-blueprints.md 
b/guide/blueprints/chef/creating-blueprints.md
index 8d30131..97397b9 100644
--- a/guide/blueprints/chef/creating-blueprints.md
+++ b/guide/blueprints/chef/creating-blueprints.md
@@ -9,7 +9,7 @@ In a nutshell, a new Chef-based entity can be defined as a 
service by specifying
 An illustrative example is below:
 
 {% highlight yaml %}
-{% readj example_yaml/mysql-chef-1.yaml %}
+{% read example_yaml/mysql-chef-1.yaml %}
 {% endhighlight %}
 
 *This works without any installation: try it now, copying-and-pasting to the 
Brooklyn console.
diff --git a/guide/blueprints/clusters-and-policies.md 
b/guide/blueprints/clusters-and-policies.md
index 0e9630f..4c398bc 100644
--- a/guide/blueprints/clusters-and-policies.md
+++ b/guide/blueprints/clusters-and-policies.md
@@ -13,7 +13,7 @@ It takes the same `dynamiccluster.memberspec`, so we can 
build a fully functiona
 deployment of our `hello-world-sql` application as follows:
 
 {% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db.yaml %}
+{% read example_yaml/appserver-clustered-w-db.yaml %}
 {% endhighlight %}
 
 This sets up Nginx as the controller by default, but that can be configured
@@ -26,7 +26,7 @@ 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 %}
+{% read example_yaml/appserver-clustered-w-db-concise.yaml %}
 {% endhighlight %}
  
 The other nicety supplied by the `ControlledDynamicWebAppCluster` blueprint is 
that
@@ -38,7 +38,7 @@ We can set up our blueprint to do autoscaling based on 
requests per second
 as follows: 
 
 {% highlight yaml %}
-{% readj example_yaml/appserver-w-policy.yaml %}
+{% read example_yaml/appserver-w-policy.yaml %}
 {% endhighlight %}
 
 Use your favorite load-generation tool (`jmeter` is one good example) to send 
a huge
diff --git a/guide/blueprints/clusters.md b/guide/blueprints/clusters.md
index 5e46adc..e0f0b03 100644
--- a/guide/blueprints/clusters.md
+++ b/guide/blueprints/clusters.md
@@ -9,7 +9,7 @@ What if you want multiple machines? One way is just to repeat 
the `- type: org.a
 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 %}
+{% read example_yaml/cluster-vm.yaml %}
 {% endhighlight %}
 
 Here we've composed the previous blueprint introducing some new important 
concepts, the `DynamicCluster`
diff --git a/guide/blueprints/configuring-vms.md 
b/guide/blueprints/configuring-vms.md
index 8582895..d98e50b 100644
--- a/guide/blueprints/configuring-vms.md
+++ b/guide/blueprints/configuring-vms.md
@@ -8,7 +8,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 %}
+{% read example_yaml/simple-vm.yaml %}
 {% endhighlight %}
 
 
diff --git a/guide/blueprints/creating-yaml.md 
b/guide/blueprints/creating-yaml.md
index 7f00252..5af93c7 100644
--- a/guide/blueprints/creating-yaml.md
+++ b/guide/blueprints/creating-yaml.md
@@ -19,7 +19,7 @@ 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 %}
+{% read example_yaml/simple-appserver.yaml %}
 {% endhighlight %}
 
 * The `name` is just for the benefit of us humans.
diff --git a/guide/blueprints/custom-entities.md 
b/guide/blueprints/custom-entities.md
index 8eeaa27..dd498cd 100644
--- a/guide/blueprints/custom-entities.md
+++ b/guide/blueprints/custom-entities.md
@@ -20,7 +20,7 @@ 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 %}
+{% read example_yaml/vanilla-bash-netcat.yaml %}
 {% endhighlight %}
 
 This starts a simple `nc` listener on port 4321 which will respond `hello` to 
the first
@@ -50,7 +50,7 @@ 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 %}
+{% read example_yaml/vanilla-bash-netcat-file.yaml %}
 {% endhighlight %}
 
 
@@ -74,7 +74,7 @@ as documented on the javadoc and config keys of the
 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 %}
+{% read example_yaml/vanilla-bash-netcat-more-commands.yaml %}
 {% endhighlight %}
 
 
@@ -97,7 +97,7 @@ 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 %}
+{% read example_yaml/vanilla-bash-netcat-port.yaml %}
 {% endhighlight %}
 
 The regex for ports to be opened can be configured using
@@ -127,7 +127,7 @@ Blueprint scripts can be parametrised through environment 
variables, making them
 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 %}
+{% read example_yaml/vanilla-bash-netcat-env.yaml %}
 {% endhighlight %}
 
 Non-string objects in the `env` map will be serialized to JSON before passing 
them to the script.
@@ -139,7 +139,7 @@ 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 %}
+{% read example_yaml/vanilla-bash-netcat-port-parameter.yaml %}
 {% endhighlight %}
 
 The example above will allow a user to specify a message to send back
@@ -167,7 +167,7 @@ The *Catalog* component allows you to add blueprints which 
you can refer to in o
 In that tab, click *+* then *YAML*, and enter the following:
 
 {% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-catalog.bom %}
+{% read example_yaml/vanilla-bash-netcat-catalog.bom %}
 {% endhighlight %}
 
 This is the same example as in the previous section, wrapped according to the 
catalog YAML requirements,
@@ -179,7 +179,7 @@ With this added to the catalog, we can reference the type 
`netcat-example` when
 Return to the *Home* or *Applications* tab, click *+*, and submit this YAML 
blueprint:
 
 {% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-reference.yaml %}
+{% read example_yaml/vanilla-bash-netcat-reference.yaml %}
 {% endhighlight %}
 
 This extends the previous blueprint which we registered in the catalog,
@@ -191,7 +191,7 @@ 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 %}
+{% read example_yaml/vanilla-bash-netcat-cluster.yaml %}
 {% endhighlight %}
 
 In either of the above examples, if you explore the tree in the *Applications* 
view
@@ -207,7 +207,7 @@ Besides detecting this failure, Brooklyn policies can be 
added to the YAML to ta
 action. A simple recovery here might be just to restart the process 
automatically:
 
 {% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-restarter.yaml %}
+{% read example_yaml/vanilla-bash-netcat-restarter.yaml %}
 {% endhighlight %}
 
 Autonomic management in Brooklyn often follows the principle that complex 
behaviours emerge
diff --git a/guide/blueprints/enrichers.md b/guide/blueprints/enrichers.md
index 6ef1247..4d97e45 100644
--- a/guide/blueprints/enrichers.md
+++ b/guide/blueprints/enrichers.md
@@ -15,7 +15,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 %}
+{% read example_yaml/enricher-transformer.yaml %}
 {% endhighlight %}
 
 #### Propagator
@@ -27,7 +27,7 @@ The other use of Propagator is where you specify a producer 
(using `$brooklyn:en
 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 %}
+{% read example_yaml/enricher-propagator.yaml %}
 {% endhighlight %}
 
 #### Custom Aggregating
@@ -37,7 +37,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 %}
+{% read example_yaml/enricher-aggregator.yaml %}
 {% endhighlight %}
 
 There are a number of additional configuration keys available for the 
Aggregators:
@@ -55,7 +55,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 %}
+{% read example_yaml/enricher-joiner.yaml %}
 {% endhighlight %}
 
 There are a number of additional configuration keys available for the joiner:
@@ -82,7 +82,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 %}
+{% read example_yaml/enricher-time-weighted-delta.yaml %}
 {% endhighlight %}
 
 ####   Rolling Mean
@@ -131,7 +131,7 @@ is actually a sensor on a different entity called 
`load.balancer`. In this case,
 `enricher.producer` value.
 
 {% highlight yaml %}
-{% readj example_yaml/enricher-transformer.yaml %}
+{% read example_yaml/enricher-transformer.yaml %}
 {% endhighlight %}
 
 It is important to note that the value supplied to `enricher.producer` must be 
immediately resolvable. While it would be valid
diff --git a/guide/blueprints/java/defining-and-deploying.md 
b/guide/blueprints/java/defining-and-deploying.md
index bda3696..f516d3c 100644
--- a/guide/blueprints/java/defining-and-deploying.md
+++ b/guide/blueprints/java/defining-and-deploying.md
@@ -40,7 +40,7 @@ configuration options, sensors, and effectors). The code 
below assumes you have
 in the package `com.acme` for `src/main/java`.
 
 {% highlight java %}
-{% readj gist_generator/GistGenerator.java %}
+{% read gist_generator/GistGenerator.java %}
 {% endhighlight %}
 
 To describe each part of this:
@@ -64,7 +64,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 %}
+{% read gist_generator/GistGeneratorImpl.java %}
 {% endhighlight %}
 
 To describe each part of this:
@@ -110,7 +110,7 @@ You will need to substitute the github access token you 
generated in the previou
 the placeholder text `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`.
 
 {% highlight java %}
-{% readj gist_generator/GistGeneratorTest.java %}
+{% read gist_generator/GistGeneratorTest.java %}
 {% endhighlight %}
 
 Similarly, we can write a test that uses the `GistGenerator` from a YAML 
blueprint. 
@@ -123,7 +123,7 @@ the placeholder text 
`xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`. See the section
 for how to store these credentials more securely. 
 
 {% highlight java %}
-{% readj gist_generator/GistGeneratorYamlTest.java %}
+{% read gist_generator/GistGeneratorYamlTest.java %}
 {% endhighlight %}
 
 
@@ -146,7 +146,7 @@ to add our `GistGenerator` to the catalog. Substitute the 
URL below for your own
 artifact (which will be in the `target` sub-directory after running `mvn clean 
install`).
 
 {% highlight yaml %}
-{% readj gist_generator/gist_generator.bom %}
+{% read gist_generator/gist_generator.bom %}
 {% endhighlight %}
 
 See [Handling Bundle 
Dependencies](/guide/blueprints/java/bundle-dependencies.html)
diff --git a/guide/blueprints/java/topology-dependencies.md 
b/guide/blueprints/java/topology-dependencies.md
index 7425f08..4a1b6e3 100644
--- a/guide/blueprints/java/topology-dependencies.md
+++ b/guide/blueprints/java/topology-dependencies.md
@@ -15,7 +15,7 @@ example](/guide/start/policies.html), but also includes the 
MySQL database
 to demonstrate the use of dependent configuration.
 
 {% highlight java %}
-{% readj java_app/ExampleWebApp.java %}
+{% read java_app/ExampleWebApp.java %}
 {% endhighlight %}
 
 To describe each part of this:
diff --git a/guide/blueprints/multiple-services.md 
b/guide/blueprints/multiple-services.md
index fed66d7..dc990d4 100644
--- a/guide/blueprints/multiple-services.md
+++ b/guide/blueprints/multiple-services.md
@@ -13,7 +13,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 %}
+{% read example_yaml/appserver-configured.yaml %}
 {% endhighlight %}
 
 (As before, you'll need to add the `location` info; `localhost` will work for 
these and subsequent examples.)
@@ -33,7 +33,7 @@ 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 %}
+{% read example_yaml/appserver-w-db.yaml %}
 {% endhighlight %}
 
 Here there are a few things going on:
@@ -81,7 +81,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 %}
+{% read example_yaml/appserver-w-db-other-flavor.yaml %}
 {% endhighlight %}
 
 By changing two lines we've switched from JBoss and MySQL to Tomcat and 
MariaDB.
diff --git a/guide/blueprints/setting-locations.md 
b/guide/blueprints/setting-locations.md
index 052b037..408c9fb 100644
--- a/guide/blueprints/setting-locations.md
+++ b/guide/blueprints/setting-locations.md
@@ -17,7 +17,7 @@ for details and more examples.
 The following example is for Amazon EC2:
 
 {% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location.yaml %}
+{% read example_yaml/simple-appserver-with-location.yaml %}
 {% endhighlight %}
 
 (You'll need to replace the `identity` and `credential` with the 
@@ -37,7 +37,7 @@ The example below shows a pool of machines that will be used 
by the entities wit
 application.
 
 {% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-byon.yaml %}
+{% read example_yaml/simple-appserver-with-location-byon.yaml %}
 {% endhighlight %}
 
 
@@ -72,7 +72,7 @@ The example below will deploy Tomcat and JBoss App Server to 
different Bring You
 locations:
 
 {% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-per-entity.yaml %}
+{% read example_yaml/simple-appserver-with-location-per-entity.yaml %}
 {% endhighlight %}
 
 The rules for precedence when defining a location for an entity are:
@@ -96,7 +96,7 @@ used for each `DynamicCluster`; all app-servers inside that 
cluster will obtain
 that given location.
 
 {% highlight yaml %}
-{% readj example_yaml/fabric-with-multiple-locations.yaml %}
+{% read example_yaml/fabric-with-multiple-locations.yaml %}
 {% endhighlight %}
 
 The entity hierarchy at runtime will have a `DynamicFabric` with two children, 
each of type 
diff --git a/guide/blueprints/test/test-entities.md 
b/guide/blueprints/test/test-entities.md
index ce4b213..eccff11 100644
--- a/guide/blueprints/test/test-entities.md
+++ b/guide/blueprints/test/test-entities.md
@@ -13,7 +13,7 @@ layout: website-normal
 The `TestCase` entity acts as a container for a list of child entities which 
are started *sequentially*.
 
 {% highlight yaml %}
-{% readj example_yaml/entities/testcase-entity.yaml %}
+{% read example_yaml/entities/testcase-entity.yaml %}
 {% endhighlight %}
 
 This can be used to enforce a strict ordering, for example ensuring a sensor 
has a certain value before attempting to invoke an effector.
@@ -32,7 +32,7 @@ The `ParallelTestCase` entity can be added as a child to run 
a subset of entitie
 The `ParallelTestCase` entity acts as a container for a list of child entities 
which are started in *parallel*.
 
 {% highlight yaml %}
-{% readj example_yaml/entities/paralleltestcase-entity.yaml %}
+{% read example_yaml/entities/paralleltestcase-entity.yaml %}
 {% endhighlight %}
 
 This can be used to run a subset of entities in parallel as a single step when 
nested under a `TestCase` entity.
@@ -44,7 +44,7 @@ Timeouts on child entities should be set relative to the 
start of the `ParallelT
 The `LoopOverGroupMembersTestCase` entity is configured with a target group 
and a test specification. For each member of the targeted group, the test case 
will create a TargetableTestComponent entity from the supplied test 
specification and set the components target to be the group member.
 
 {% highlight yaml %}
-{% readj example_yaml/entities/loopovergroupmembers-entity.yaml %}
+{% read example_yaml/entities/loopovergroupmembers-entity.yaml %}
 {% endhighlight %}
 
 #### Parameters
@@ -57,7 +57,7 @@ The `LoopOverGroupMembersTestCase` entity is configured with 
a target group and
 The `InfrastructureDeploymentTestCase` will first create and deploy an 
infrastructure from the `infrastructure.deployment.spec` config. It will then 
retrieve a deployment location by getting the value of the infrastructures 
`infrastructure.deployment.location.sensor` sensor. It will then create and 
deploy all entities from the `infrastructure.deployment.spec` config to the 
deployment location.
 
 {% highlight yaml %}
-{% readj example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml %}
+{% read example_yaml/entities/infrastructuredeploymenttestcase-entity.yaml %}
 {% endhighlight %}
 
 #### Parameters
@@ -73,7 +73,7 @@ The `InfrastructureDeploymentTestCase` will first create and 
deploy an infrastru
 The `TestSensor` entity performs an assertion on a specified sensors value.
 
 {% highlight yaml %}
-{% readj example_yaml/entities/testsensor-entity.yaml %}
+{% read example_yaml/entities/testsensor-entity.yaml %}
 {% endhighlight %}
 
 #### Parameters
@@ -93,7 +93,7 @@ The `TestSensor` entity performs an assertion on a specified 
sensors value.
 ### TestEffector
 The `TestEffector` entity invokes the specified effector on a target entity. 
If the result of the effector is a String, it will then perform assertions on 
the result.
 {% highlight yaml %}
-{% readj example_yaml/entities/testeffector-entity.yaml %}
+{% read example_yaml/entities/testeffector-entity.yaml %}
 {% endhighlight %}
 
 #### Parameters
@@ -114,7 +114,7 @@ The `TestEffector` entity invokes the specified effector on 
a target entity. If
 ### TestHttpCall
 The `TestHttpCall` entity performs a HTTP GET on the specified URL and 
performs an assertion on the response.
 {% highlight yaml %}
-{% readj example_yaml/entities/testhttpcall-entity.yaml %}
+{% read example_yaml/entities/testhttpcall-entity.yaml %}
 {% endhighlight %}
 
 #### Parameters
@@ -139,7 +139,7 @@ If no assertions are explicitly configured, the default is 
to assert a non-zero
 Either a bash command may be provided in the YAML, or a URL for a script which 
will be executed.
 
 {% highlight yaml %}
-{% readj example_yaml/entities/testsshcommand-entity.yaml %}
+{% read example_yaml/entities/testsshcommand-entity.yaml %}
 {% endhighlight %}
 
 #### Parameters
diff --git a/guide/blueprints/test/usage-examples.md 
b/guide/blueprints/test/usage-examples.md
index 4c407fa..ccfc87c 100644
--- a/guide/blueprints/test/usage-examples.md
+++ b/guide/blueprints/test/usage-examples.md
@@ -10,7 +10,7 @@ layout: website-normal
 This section describes some simple tests based on the [Getting 
Started](/guide/start/blueprints.html#launching-from-a-blueprint) example 
blueprint:
 
 {% highlight yaml %}
-{% readj /guide/start/_my-web-cluster.yaml %}
+{% read /guide/start/_my-web-cluster.yaml %}
 {% endhighlight %}
 
 The following sections contain yaml snippets that be appended to the list of 
services in the blueprint above, a complete blueprint is also provided 
[below](#full-example).
@@ -37,7 +37,7 @@ This `TestEffector` example demonstrates the use of the 
`TestCase` and `TestSens
   - asserts `/newcontext` URL returns a HTTP status code 200 within 5 minutes 
of the effector being invoked (Note that this timeout is relative to the 
preceding test entity as they are being sequentially run as children of a 
`TestCase` entity).
 
 {% highlight yaml %}
-{% readj example_yaml/testcases/effector-test-snippet.yaml %}
+{% read example_yaml/testcases/effector-test-snippet.yaml %}
 {% endhighlight %}
 
 ### HTTP Call Tests
@@ -47,7 +47,7 @@ Demonstrates the following HTTP Call assertions against the 
specified `url`, whi
 - asserts the response body matches the regex `(?s).*Br[o]{2}klyn Deployed.*` 
within 10 minutes of the blueprint being deployed. Note the presence of the 
`(?s)` dotall flag to test a multiline response.
 
 {% highlight yaml %}
-{% readj example_yaml/testcases/http-test-snippet.yaml %}
+{% read example_yaml/testcases/http-test-snippet.yaml %}
 {% endhighlight %}
 
 ### Full Example
diff --git a/guide/dev/env/ide/index.md b/guide/dev/env/ide/index.md
index b633d3a..a2bb30a 100644
--- a/guide/dev/env/ide/index.md
+++ b/guide/dev/env/ide/index.md
@@ -25,7 +25,7 @@ working with the Brooklyn project. Optionally you can install 
the
 Groovy and TestNG plugins, but they are not required for building the project.
 You can install these using Help -> Install New Software, or from the Eclipse 
Marketplace:
 
-{% readj eclipse.include.md %}
+{% read eclipse.include.md %}
 
 As of this writing, Eclipse 4.5 and Eclipse 4.4 are commonly used,
 and the codebase can be imported (Import -> Existing Maven Projects)
diff --git a/guide/ops/gui/blueprints.md b/guide/ops/gui/blueprints.md
index 8c51235..7df7355 100644
--- a/guide/ops/gui/blueprints.md
+++ b/guide/ops/gui/blueprints.md
@@ -32,7 +32,7 @@ and copy the blueprint below into the editor.
 But *before* you submit it, modify the YAML to specify the location where the 
application will be deployed.
 
 {% highlight yaml %}
-{% readj _my-web-cluster.yaml %}
+{% read _my-web-cluster.yaml %}
 {% endhighlight %}
 
 Replace the `location:` element with values for your chosen target 
environment, for example to use SoftLayer rather than AWS (updating with your 
own credentials): 
diff --git a/guide/ops/gui/policies.md b/guide/ops/gui/policies.md
index eec033a..d9a8d5b 100644
--- a/guide/ops/gui/policies.md
+++ b/guide/ops/gui/policies.md
@@ -10,7 +10,7 @@ To see an example of policy based management, please deploy 
the following bluepr
 the location details as for the example shown earlier):
 
 {% highlight yaml %}
-{% readj _my-web-cluster2.yaml %}
+{% read _my-web-cluster2.yaml %}
 {% endhighlight %}
 
 The app server cluster has an `AutoScalerPolicy`, and the loadbalancer has a 
`targets` policy.
diff --git a/website/learnmore/features/index.md 
b/website/learnmore/features/index.md
index fff6864..4a56d85 100644
--- a/website/learnmore/features/index.md
+++ b/website/learnmore/features/index.md
@@ -10,9 +10,9 @@ children:
 
 <div class="feature-list">
 
-{% readj blueprinting.md %}
-{% readj policy-based-mgmt.md %}
-{% readj operations.md %}
-{% readj java.md %}
+{% read blueprinting.md %}
+{% read policy-based-mgmt.md %}
+{% read operations.md %}
+{% read java.md %}
 
 </div>

Reply via email to