You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by he...@apache.org on 2021/07/22 23:13:10 UTC
[brooklyn-docs] branch master updated (71b0757 -> 7f8efba)
This is an automated email from the ASF dual-hosted git repository.
heneveld pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/brooklyn-docs.git.
from 71b0757 Merge branch 'links-to-md'
new 2878064 tidy the read/readj tag
new 7f8efba use simpler `read` in most places
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
README.md | 8 +++
_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 +-
.../big_examples/webcluster/webcluster.include.md | 2 +-
_extra/simple_java_examples/examples.md | 6 +-
_plugins/read.rb | 74 +++++++++++++++-------
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 +--
29 files changed, 124 insertions(+), 90 deletions(-)
[brooklyn-docs] 01/02: tidy the read/readj tag
Posted by he...@apache.org.
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 287806417f8776eec5aeedb8369568b7096ebf75
Author: Alex Heneveld <al...@cloudsoftcorp.com>
AuthorDate: Thu Jul 22 23:54:31 2021 +0100
tidy the read/readj tag
rename readj to read_jekyll,
add read_literal, and make default read be auto
---
README.md | 8 ++++++
_plugins/read.rb | 74 ++++++++++++++++++++++++++++++++++++++------------------
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/README.md b/README.md
index e562c6f..87b9aca 100644
--- a/README.md
+++ b/README.md
@@ -285,6 +285,14 @@ We use some custom Jekyll plugins, in the `_plugins` dir:
* include markdown files inside other files (see, for example, the `*.include.md` files
which contain text which is used in multiple other files)
+ * `read_jekyll` will read a file and jekyll-process it (eg for nested `{% ... readj ` calls;
+ it's just like `include_relative` but with two differences: when `readj` is used
+ nested `read_jekyll` calls are relative to the included file where it is contained,
+ rather than relative to the root md file which made the first `read_jekyll` call
+ (so in general it's more intuitive than `include_relative`),
+ and `include_relative` processes front matter whereas `read_jekyll` mangles it
+ * `read_literal` is like `read_jekyll` but without the jekyll/tag processing
+ * `read` will autodetect based on filename -- jekyll for `*.md` and literal for all others
* generate the site structure / menu objects
* parse JSON which we can loop over in our markdown docs (to build up models; previously used
for the TOC in the guide, but now replaced with site_structure)
diff --git a/_plugins/read.rb b/_plugins/read.rb
index 23cf0f2..af910bb 100644
--- a/_plugins/read.rb
+++ b/_plugins/read.rb
@@ -21,7 +21,7 @@
# (like include, but in the dir where it is invoked)
# there is also readj which reads a file and applies jekyll processing to it
-# handy if we want to include a toc.json file which itself calls {% readj child/toc.json %}
+# handy if we want to include a toc.json file which itself calls {% read_jekyll child/toc.json %}
# (note however variables do not seem to be exported when use readj (TODO),
# although they are exported if you have _includes/file.md and use the standard include file)
@@ -35,47 +35,73 @@ module JekyllRead
def initialize(tag_name, text, tokens)
super
@text = text
+ @mode = :auto
end
- def render(context)
- filename = @text.strip
- filename = context[filename] || filename
+ def load_file(context, filename, context_page)
# Pathname API ignores first arg below if second is absolute
- file = Pathname.new(File.dirname(context['page']['path'])) + filename
+ file = Pathname.new(File.dirname(context_page['path'])) + filename
file = file.cleanpath
+
# is there a better way to trim a leading / ?
file = file.relative_path_from(Pathname.new("/")) unless file.relative?
raise "No such file #{file} in read call (from #{context['page']['path']})" unless file.exist?
+ file
+ end
+
+ def render_jekyll(context, filename)
+ file = load_file(context, filename, context['page'] || context.registers[:page])
+
+ # support vars and paths relative to a file being readj'd
+ jekyllSite = context.registers[:site]
+ targetPage = Jekyll::Page.new(jekyllSite, jekyllSite.source, File.dirname(file), File.basename(file))
+ targetPage.render(jekyllSite.layouts, jekyllSite.site_payload)
+ targetPage.output
+ end
+
+ def render_literal(context, filename)
+ file = load_file(context, filename, context['page'])
file = File.open(file, "rb")
return file.read
end
+
+ def render(context)
+ filename = @text.strip
+ context[filename] || filename
+
+ mode = @mode
+ if (mode == :auto)
+ mode = filename.end_with?(".md") ? :jekyll : :literal
+ end
+ if (mode == :jekyll)
+ render_jekyll(context, filename)
+ elsif (mode == :literal)
+ render_literal(context, filename)
+ else
+ raise "Unknown mode #{mode}"
+ end
+
+ end
end
- class ReadjTag < Liquid::Tag
+ class ReadJekyllTag < ReadTag
def initialize(tag_name, text, tokens)
super
- @text = text
+ @mode = :jekyll
end
- def render(context)
- filename = @text.strip
- filename = context[filename] || filename
- # Pathname API ignores first arg below if second is absolute
- page = context['page'] || context.registers[:page]
- file = Pathname.new(File.dirname(page['path'])) + filename
- file = file.cleanpath
- # is there a better way to trim a leading / ?
- file = file.relative_path_from(Pathname.new("/")) unless file.relative?
- raise "No such file #{file} in readj call (from #{context['page']['path']})" unless file.exist?
-
- # with readj we support vars and paths relative to a file being readj'd
- jekyllSite = context.registers[:site]
- targetPage = Jekyll::Page.new(jekyllSite, jekyllSite.source, File.dirname(file), File.basename(file))
- targetPage.render(jekyllSite.layouts, jekyllSite.site_payload)
- return targetPage.output
+ end
+ class ReadLiteralTag < ReadTag
+ def initialize(tag_name, text, tokens)
+ super
+ @mode = :literal
end
end
end
Liquid::Template.register_tag('read', JekyllRead::ReadTag)
-Liquid::Template.register_tag('readj', JekyllRead::ReadjTag)
+Liquid::Template.register_tag('read_jekyll', JekyllRead::ReadJekyllTag)
+Liquid::Template.register_tag('read_literal', JekyllRead::ReadLiteralTag)
+
+# for compatibility with old markdown
+Liquid::Template.register_tag('readj', JekyllRead::ReadJekyllTag)
[brooklyn-docs] 02/02: use simpler `read` in most places
Posted by he...@apache.org.
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 <al...@cloudsoftcorp.com>
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>