brooklyn-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From henev...@apache.org
Subject [38/44] incubator-brooklyn git commit: Continues restructuring of Java section
Date Fri, 09 Jan 2015 15:35:07 GMT
Continues restructuring of Java section


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

Branch: refs/heads/master
Commit: a71a7df8bcc9f61b0b6ff62c19e6b46f4706fe7b
Parents: 29dae4c
Author: Robert Moss <robertgmoss@gmail.com>
Authored: Fri Jan 9 11:39:30 2015 +0000
Committer: Robert Moss <robertgmoss@gmail.com>
Committed: Fri Jan 9 15:19:29 2015 +0000

----------------------------------------------------------------------
 docs/guide/java/defining-and-deploying.md       | 123 ++++++++++
 docs/guide/java/entities.md                     | 126 ++++++++++
 docs/guide/java/entities/index.md               | 131 ----------
 docs/guide/java/index.md                        |  11 +-
 docs/guide/java/policies.md                     | 123 ++++++++++
 docs/guide/java/policies/index.md               | 127 ----------
 ...topology-dependencies-management-policies.md |  69 ++++++
 .../java/walkthrough/_java_walkthrough_p1.md    | 238 -------------------
 docs/guide/java/walkthrough/index.md            |   7 -
 .../walkthrough/wt-deployed-application-700.png | Bin 176494 -> 0 bytes
 .../walkthrough/wt-deployed-application.png     | Bin 127347 -> 0 bytes
 docs/guide/java/walkthrough/wt-starting-700.png | Bin 303892 -> 0 bytes
 docs/guide/java/walkthrough/wt-starting.png     | Bin 332710 -> 0 bytes
 .../walkthrough/wt-tree-jboss-sensors-700.png   | Bin 268853 -> 0 bytes
 .../java/walkthrough/wt-tree-jboss-sensors.png  | Bin 169929 -> 0 bytes
 docs/guide/java/wt-deployed-application-700.png | Bin 0 -> 176494 bytes
 docs/guide/java/wt-deployed-application.png     | Bin 0 -> 127347 bytes
 docs/guide/java/wt-starting-700.png             | Bin 0 -> 303892 bytes
 docs/guide/java/wt-starting.png                 | Bin 0 -> 332710 bytes
 docs/guide/java/wt-tree-jboss-sensors-700.png   | Bin 0 -> 268853 bytes
 docs/guide/java/wt-tree-jboss-sensors.png       | Bin 0 -> 169929 bytes
 21 files changed, 448 insertions(+), 507 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/defining-and-deploying.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/defining-and-deploying.md b/docs/guide/java/defining-and-deploying.md
new file mode 100644
index 0000000..084b4f6
--- /dev/null
+++ b/docs/guide/java/defining-and-deploying.md
@@ -0,0 +1,123 @@
+---
+title: Defining and Deploying
+layout: guide-normal
+---
+
+## Intro
+
+This walkthrough will set up a sample application which you can use as foundation for creating your own applications.
+
+The sample application is a three tier web service, composed of:
+
+* an Nginx load-balancer
+* a cluster of JBoss appservers
+* a MySQL database
+
+## Define your Application Blueprint
+
+An application blueprint is defined as a Java class, as follows:
+
+{% highlight java %}
+public class ClusterWebServerDatabaseSample extends AbstractApplication {
+    @Override
+    public void init() {
+        MySqlNode mysql = addChild(EntitySpec.create(MySqlNode.class));
+        ControlledDynamicWebAppCluster web = addChild(EntitySpec.create(ControlledDynamicWebAppCluster.class));
+    }
+}
+{% endhighlight %}
+
+The file `ClusterWebServerDatabaseSample.java` in `src/main/java/com/acme/sample/brooklyn/sample/app/` 
+provides a template to follow.
+
+
+## Deploying the Application
+
+If you have not already done so, follow the section in the 
+[Getting Started Guide]({{site.path.guide}}/use/guide/quickstart/index.html) to create a `brooklyn.properties` 
+file containing credentials for your preferred cloud provider. 
+
+To launch this application, build the project and run the `start.sh` script in the resulting assembly:
+
+{% highlight bash %}
+$ mvn clean assembly:assembly
+
+$ cd target/brooklyn-sample-0.1.0-SNAPSHOT-dist/brooklyn-sample-0.1.0-SNAPSHOT/
+
+$ ./start.sh launch \
+    --app com.acme.sample.brooklyn.sample.app.ClusterWebServerDatabaseSample \
+    --location jclouds:aws-ec2:eu-west-1
+{% endhighlight %}
+
+(Amazon is used in this walkthrough, but lots of targets are supported,
+including `--location localhost`, fixed IP addresses, and 
+everything supported by [jclouds](http://jclouds.org), from OpenStack to Google Compute.)
+
+Your console will inform you that it has started a Brooklyn console at [http://localhost:8081](http://localhost:8081)
+
+[![Web Console]({{ page.url_basedir }}wt-starting-700.png "Web Console")](wt-starting.png) 
+
+The management console provides a view on to the entities that launched,
+including the hierarchy (appservers grouped into a cluster) and their locations. 
+
+Brooklyn collects information from these entities ("sensors"), 
+aggregates these for clusters and other groups (using "enrichers"),
+and exposes operations ("effectors") that can be performed on entities.
+
+[![Web Console Details]({{ page.url_basedir }}wt-tree-jboss-sensors-700.png "Web Console Details")](wt-tree-jboss-sensors.png) 
+
+## What Next?
+ 
+In addition to the sample project created by the archetype, with its README and
+`assembly` build, you can find additional code related to this example included with Brooklyn as the ``simple-web-cluster`` example,
+described [in detail here]({{site.path.guide}}/use/examples/webcluster).
+
+For your applications, you might want to mix in other data stores, messaging systems, or on-line services including PaaS.
+Brooklyn supports some of these out-of-the-box, including a wide-range of tools which it can use Whirr to provision, such as Hadoop.
+But if you have something you don't see, 
+[let us know]({{site.path.guide}}/meta/contact.html) -- 
+we want to work with you to 
+[write a new entity]({{site.path.guide}}/dev/code/entity.html) or
+[policy]({{site.path.guide}}/dev/code/policy.html) 
+and [contribute it]({{site.path.guide}}/dev/how-to-contrib.html).
+
+
+<!--
+
+Alternatively you can just add a ``main`` method to the application class as follows:
+
+{% highlight java %}
+    public static void main(String[] argv) {
+        List<String> args = Lists.newArrayList(argv);
+        String port =  CommandLineUtil.getCommandLineOption(args, "--port", "8081+");
+        String location = CommandLineUtil.getCommandLineOption(args, "--location", DEFAULT_LOCATION);
+
+        BrooklynServerDetails server = BrooklynLauncher.newLauncher()
+                .webconsolePort(port)
+                .launch();
+
+        Location loc = server.getManagementContext().getLocationRegistry().resolve(location);
+
+        StartableApplication app = new WebClusterDatabaseExample()
+                .appDisplayName("Brooklyn WebApp Cluster with Database example")
+                .manage(server.getManagementContext());
+        
+        app.start(ImmutableList.of(loc));
+        
+        Entities.dumpInfo(app);
+    }
+{% endhighlight %}
+
+Compile and run this with the [``brooklyn-all`` jar]({{site.path.guide}}/start/download.html) on the classpath,
+pointing at your favourite WAR on your filesystem. 
+(If the ``import`` packages aren't picked up correctly,
+you can cheat by looking at [the file in Github](https://github.com/apache/incubator-brooklyn/blob/master/examples/simple-web-cluster/src/main/java/brooklyn/demo/WebClusterDatabaseExample.java);
+and you'll find a sample WAR which uses the database as configured above 
+[here](https://http://ccweb.cloudsoftcorp.com/maven/libs-snapshot-local/io/brooklyn/).)
+ TODO example webapp url 
+ 
+If you want to adventure beyond ``localhost`` (the default),
+simply supply the your favourite cloud (e.g. ``aws-ec2:eu-west-1``)
+with credentials set up as described [here]({{ site.path.guide }}/use/guide/management/index.html#startup-config).
+
+-->

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/entities.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/entities.md b/docs/guide/java/entities.md
new file mode 100644
index 0000000..f529762
--- /dev/null
+++ b/docs/guide/java/entities.md
@@ -0,0 +1,126 @@
+---
+title: Custom Entity Development
+layout: guide-normal
+---
+
+This section details how to create new custom application components or groups as brooklyn entities.
+
+The Entity Lifecycle
+--------------------
+
+- Importance of serialization, ref to How mananagement works
+- Parents and Membership (groups)
+
+What to Extend -- Implementation Classes
+----------------------------------------
+
+- entity implementation class hierarchy
+
+  - ``SoftwareProcess`` as the main starting point for base entities (corresponding to software processes),
+    and subclasses such as ``VanillaJavaApp``
+  - ``DynamicCluster`` (multiple instances of the same entity in a location) and 
+    ``DynamicFabric`` (clusters in multiple location) for automatically creating many instances,
+    supplied with an ``EntityFactory`` (e.g. ``BaseEntityFactory``) in the ``factory`` flag
+  - abstract ``Group`` for collecting entities which are parented elsewhere in the hierachy
+  - ``AbstractEntity`` if nothing else fits
+  
+- traits (mixins, otherwise known as interfaces with statics) to define available config keys, sensors, and effectors;
+    and conveniences e.g. ``StartableMethods.{start,stop}`` is useful for entities which implement ``Startable``
+
+- the ``Entities`` class provides some generic convenience methods; worth looking at it for any work you do
+
+A common lifecycle pattern is that the ``start`` effector (see more on effectors below) is invoked, 
+often delegating either to a driver (for software processes) or children entities (for clusters etc).
+
+See ``JBoss7Server`` and ``MySqlNode`` for exemplars.
+
+
+Configuration
+-------------
+<!---
+TODO: why to use config?
+-->
+
+- AttributeSensorAndConfigKey fields can be automatically converted for ``SoftwareProcess``. 
+  This is done in ``preStart()``. This must be done manually if required for other entities,
+  often with ``ConfigToAttributes.apply(this)``.
+
+- Setting ports is a special challenge, and one which the ``AttributeSensorAndConfigKey`` is particularly helpful for,
+  cf ``PortAttributeSensorAndConfigKey`` (a subclass),
+  causing ports automatically get assigned from a range and compared with the target ``PortSupplied`` location.
+  
+  Syntax is as described in the PortRange interface. For example, "8080-8099,8800+" will try port 8080, try sequentially through 8099, then try from 8800 until all ports are exhausted.
+  
+  This is particularly useful on a contended machine (localhost!). Like ordinary configuration, the config is done by the user, and the actual port used is reported back as a sensor on the entity.
+ 
+ 
+Implementing Sensors
+--------------------
+
+- e.g. HTTP, JMX
+
+Sensors at base entities are often retrieved by feeds which poll the entity's corresponding instance in the real world.
+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 %}
+public void connectSensors() {
+	super.connectSensors()
+	
+    httpFeed = HttpFeed.builder()
+            .entity(this)
+            .period(200)
+            .baseUri(mgmtUrl)
+            .poll(new HttpPollConfig<Boolean>(SERVICE_UP)
+                    .onSuccess(HttpValueFunctions.responseCodeEquals(200))
+                    .onError(Functions.constant(false)))
+            .poll(new HttpPollConfig<Integer>(REQUEST_COUNT)
+                    .onSuccess(HttpValueFunctions.jsonContents("requestCount", Integer.class)))
+            .build();
+}
+    
+@Override
+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.
+We retrieve the request count from the response body, and convert it to an integer.
+
+Note the first line (``super.connectSensors()``); as one descends into specific convenience subclasses (such as for Java web-apps), the work done by the parent class's overridden methods may be relevant, and will want to be invoked or even added to a resulting list.
+
+For some sensors, and often at compound entities, the values are obtained by monitoring values of other sensors on the same (in the case of a rolling average) or different (in the case of the average of children nodes) entities. This is achieved by policies, described below.
+
+Implementing Effectors
+----------------------
+
+The ``Entity`` interface defines the sensors and effectors available. The entity class provides 
+wiring for the sensors, and the effector implementations. In simple cases it may be straightforward 
+to capture the behaviour of the effectors in a simple methods.
+For example deploying a WAR to a cluster can be done as follows:
+
+*This section is not complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
+
+<!---
+TODO show an effector which recurses across children
+-->
+
+For some entities, specifically base entities, the implementation of effectors might need other tools (such as SSH), and may vary by location, so having a single implementation is not appropriate.
+
+The problem of multiple inheritance (e.g. SSH functionality and entity inheritance) and multiple implementations (e.g. SSH versus Windows) is handled in brooklyn using delegates called _drivers_. 
+
+In the implementations of ``JavaWebApp`` entities, the behaviour which the entity always does is captured in the entity class (for example, breaking deployment of multiple WARs into atomic actions), whereas implementations which is specific to a particular entity and driver (e.g. using scp to copy the WARs to the right place and install them, which of course is different among appservers, or using an HTTP or JMX management API, again where details vary between appservers) is captured in a driver class.
+
+Routines which are convenient for specific drivers can then be inherited in the driver class hierarchy. For example, when passing JMX environment variables to Java over SSH, ``JavaSoftwareProcessSshDriver`` extends ``AbstractSoftwareProcessSshDriver`` and parents ``JBoss7SshDriver``.
+
+<!---
+TODO more drivers such as jmx, etc are planned
+-->
+
+Testing
+-------
+
+* Run in a mock ``SimulatedLocation``, defining new metaclass methods to be able to start there and assert the correct behaviour when that is invoked

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/entities/index.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/entities/index.md b/docs/guide/java/entities/index.md
deleted file mode 100644
index 90ffabf..0000000
--- a/docs/guide/java/entities/index.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: Custom Entity Development
-layout: guide-normal
----
-
-This section details how to create new custom application components or groups as brooklyn entities.
-
-<a name="entity-lifestyle"></a>
-The Entity Lifecycle
---------------------
-
-- Importance of serialization, ref to How mananagement works
-- Parents and Membership (groups)
-
-<a name="implementation-classes"></a>
-What to Extend -- Implementation Classes
-----------------------------------------
-
-- entity implementation class hierarchy
-
-  - ``SoftwareProcess`` as the main starting point for base entities (corresponding to software processes),
-    and subclasses such as ``VanillaJavaApp``
-  - ``DynamicCluster`` (multiple instances of the same entity in a location) and 
-    ``DynamicFabric`` (clusters in multiple location) for automatically creating many instances,
-    supplied with an ``EntityFactory`` (e.g. ``BaseEntityFactory``) in the ``factory`` flag
-  - abstract ``Group`` for collecting entities which are parented elsewhere in the hierachy
-  - ``AbstractEntity`` if nothing else fits
-  
-- traits (mixins, otherwise known as interfaces with statics) to define available config keys, sensors, and effectors;
-    and conveniences e.g. ``StartableMethods.{start,stop}`` is useful for entities which implement ``Startable``
-
-- the ``Entities`` class provides some generic convenience methods; worth looking at it for any work you do
-
-A common lifecycle pattern is that the ``start`` effector (see more on effectors below) is invoked, 
-often delegating either to a driver (for software processes) or children entities (for clusters etc).
-
-See ``JBoss7Server`` and ``MySqlNode`` for exemplars.
-
-
-<a name="configuration"></a>
-Configuration
--------------
-<!---
-TODO: why to use config?
--->
-
-- AttributeSensorAndConfigKey fields can be automatically converted for ``SoftwareProcess``. 
-  This is done in ``preStart()``. This must be done manually if required for other entities,
-  often with ``ConfigToAttributes.apply(this)``.
-
-- Setting ports is a special challenge, and one which the ``AttributeSensorAndConfigKey`` is particularly helpful for,
-  cf ``PortAttributeSensorAndConfigKey`` (a subclass),
-  causing ports automatically get assigned from a range and compared with the target ``PortSupplied`` location.
-  
-  Syntax is as described in the PortRange interface. For example, "8080-8099,8800+" will try port 8080, try sequentially through 8099, then try from 8800 until all ports are exhausted.
-  
-  This is particularly useful on a contended machine (localhost!). Like ordinary configuration, the config is done by the user, and the actual port used is reported back as a sensor on the entity.
- 
-<a name="implementing-sensors"></a>
-Implementing Sensors
---------------------
-
-- e.g. HTTP, JMX
-
-Sensors at base entities are often retrieved by feeds which poll the entity's corresponding instance in the real world.
-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 %}
-public void connectSensors() {
-	super.connectSensors()
-	
-    httpFeed = HttpFeed.builder()
-            .entity(this)
-            .period(200)
-            .baseUri(mgmtUrl)
-            .poll(new HttpPollConfig<Boolean>(SERVICE_UP)
-                    .onSuccess(HttpValueFunctions.responseCodeEquals(200))
-                    .onError(Functions.constant(false)))
-            .poll(new HttpPollConfig<Integer>(REQUEST_COUNT)
-                    .onSuccess(HttpValueFunctions.jsonContents("requestCount", Integer.class)))
-            .build();
-}
-    
-@Override
-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.
-We retrieve the request count from the response body, and convert it to an integer.
-
-Note the first line (``super.connectSensors()``); as one descends into specific convenience subclasses (such as for Java web-apps), the work done by the parent class's overridden methods may be relevant, and will want to be invoked or even added to a resulting list.
-
-For some sensors, and often at compound entities, the values are obtained by monitoring values of other sensors on the same (in the case of a rolling average) or different (in the case of the average of children nodes) entities. This is achieved by policies, described below.
-
-<a name="implementing-effectors"></a>
-Implementing Effectors
-----------------------
-
-The ``Entity`` interface defines the sensors and effectors available. The entity class provides 
-wiring for the sensors, and the effector implementations. In simple cases it may be straightforward 
-to capture the behaviour of the effectors in a simple methods.
-For example deploying a WAR to a cluster can be done as follows:
-
-*This section is not complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
-
-<!---
-TODO show an effector which recurses across children
--->
-
-For some entities, specifically base entities, the implementation of effectors might need other tools (such as SSH), and may vary by location, so having a single implementation is not appropriate.
-
-The problem of multiple inheritance (e.g. SSH functionality and entity inheritance) and multiple implementations (e.g. SSH versus Windows) is handled in brooklyn using delegates called _drivers_. 
-
-In the implementations of ``JavaWebApp`` entities, the behaviour which the entity always does is captured in the entity class (for example, breaking deployment of multiple WARs into atomic actions), whereas implementations which is specific to a particular entity and driver (e.g. using scp to copy the WARs to the right place and install them, which of course is different among appservers, or using an HTTP or JMX management API, again where details vary between appservers) is captured in a driver class.
-
-Routines which are convenient for specific drivers can then be inherited in the driver class hierarchy. For example, when passing JMX environment variables to Java over SSH, ``JavaSoftwareProcessSshDriver`` extends ``AbstractSoftwareProcessSshDriver`` and parents ``JBoss7SshDriver``.
-
-<!---
-TODO more drivers such as jmx, etc are planned
--->
-
-<a name="testing"></a>
-Testing
--------
-
-* Run in a mock ``SimulatedLocation``, defining new metaclass methods to be able to start there and assert the correct behaviour when that is invoked

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/index.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/index.md b/docs/guide/java/index.md
index a314a92..eb58e8a 100644
--- a/docs/guide/java/index.md
+++ b/docs/guide/java/index.md
@@ -3,13 +3,14 @@ title: Java Blueprints
 title_in_menu: Java Blueprints
 layout: website-normal
 children:
-- walkthrough/
-- common-usage.md
 - archetype.md
+- defining-and-deploying.md
+- topology-dependencies-management-policies.md
+- common-usage.md
 - entity.md
-- entities/
+- entities.md
 - policy.md
-- policies/
+- policies.md
 - service-state.md
 ---
 
@@ -17,3 +18,5 @@ Java blueprints are much more powerful than YAML but is also rather more difficu
 Advanced Java skills are required.
 
 {% include list-children.html %}
+
+Brooklyn makes it easy to describe the structure and management of sophisticated distributed applications, and then it makes it easy to launch them in a cloud, with on-going automated management.

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/policies.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/policies.md b/docs/guide/java/policies.md
new file mode 100644
index 0000000..5bc8289
--- /dev/null
+++ b/docs/guide/java/policies.md
@@ -0,0 +1,123 @@
+---
+title: Policies
+layout: guide-normal
+
+---
+
+Policies perform the active management enabled by Brooklyn.  
+They can subscribe to entity sensors and be triggered by them or they can run periodically.
+
+<!---
+TODO, clarify below, memebers of what?
+-->
+Policies can add subscriptions to sensors on any entity. Normally a policy will subscribe to its related entity, to the child entities, and/or those entities which are members.
+
+When a policy runs it can:
+
+*	perform calculations,
+*	look up other values,
+*	invoke efectors  (management policies) or,
+*	cause the entity associated with the policy to emit sensor values (enricher policies). 
+
+Entities can have zero or more ``Policy`` instances attached to them.
+
+Writing Policies
+----------------
+
+### Sample Policy
+
+<!---
+TODO
+-->
+
+*This section is not complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
+
+### Best Practice
+
+The following recommendations should be considered when designing policies:
+	
+#### Management should take place as "low" as possible in the hierarchy
+*	place management responsibility in policies at the entity, as much as possible ideally management should take run as a policy on the relevant entity
+
+*	place escalated management responsibility at the parent entity. Where this is impractical, perhaps because two aspects of an entity are best handled in two different places, ensure that the separation of responsibilities is documented and there is a group membership relationship between secondary/aspect managers.
+
+
+#### Policies should be small and composable
+<!-- 
+TODO Requires Content
+-->
+
+e.g. one policy which takes a sensor and emits a different, enriched sensor, and a second policy which responds to the enriched sensor of the first 	(e.g. a policy detects a process is maxed out and emits a TOO_HOT sensor; a second policy responds to this by scaling up the VM where it is running, requesting more CPU)
+#### Where a policy cannot resolve a situation at an entity, the issue should be escalated to a manager with a compatible policy.
+
+Typically escalation will go to the entity parent, and then cascade up.
+e.g. if the earlier VM CPU cannot be increased, the TOO_HOT event may go to the parent, a cluster entity, which attempts to balance. If the cluster cannot balance, then to another policy which attempts to scale out the cluster, and should the cluster be unable to scale, to a third policy which emits TOO_HOT for the cluster.
+	
+#### Management escalation should be carefully designed so that policies are not incompatible
+
+Order policies carefully, and mark sensors as "handled" (or potentially "swallow" them locally), so that subsequent policies and parent entities do not take superfluous (or contradictory) corrective action.
+      
+
+For this release, some of the mechanisms for implementing the above practices are still being developed.
+
+### Implementation Classes
+
+*This section is not complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
+
+- extend ``AbstractPolicy``, or override an existing policy
+
+
+Off-the-Shelf Policies
+----------------------
+
+Policies are highly reusable as their inputs, thresholds and targets are customizable.
+
+### Management Policies
+- Resizer Policy
+   
+   Increases or decreases the size of a Resizable entity based on an aggregate sensor value, the current size of the entity, and customized high/low watermarks.
+
+   A Resizer policy can take any sensor as a metric, have its watermarks tuned live, and target any resizable entity - be it an application server managing how many instances it handles, or a tier managing global capacity.
+
+   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.
+  
+<!---
+TODO - list some
+TODO - describe how they can be customised (briefly mention sensors)
+-->
+
+
+###  Enricher Policies
+
+*	Delta
+
+	Converts absolute sensor values into a delta.
+	
+
+*	Time-weighted Delta
+
+	Converts absolute sensor values into a delta/second.
+	
+*	Rolling Mean
+
+	Converts the last *N* sensor values into a mean.
+	
+*	Rolling Time-window Mean
+
+	Converts the last *N* seconds of sensor values into a weighted mean.
+
+*	Custom Aggregating
+
+	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. 
+
+Implementing Policies
+---------------------
+
+<!---
+TODO
+-->
+
+*This section is not yet complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
+
+Please see the class* ``brooklyn.policy.Policy`` *and implementations.
+

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/policies/index.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/policies/index.md b/docs/guide/java/policies/index.md
deleted file mode 100644
index 642237b..0000000
--- a/docs/guide/java/policies/index.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: Policies
-layout: guide-normal
-
----
-<a name="introduction"></a>
-
-Policies perform the active management enabled by Brooklyn.  
-They can subscribe to entity sensors and be triggered by them or they can run periodically.
-
-<!---
-TODO, clarify below, memebers of what?
--->
-Policies can add subscriptions to sensors on any entity. Normally a policy will subscribe to its related entity, to the child entities, and/or those entities which are members.
-
-When a policy runs it can:
-
-*	perform calculations,
-*	look up other values,
-*	invoke efectors  (management policies) or,
-*	cause the entity associated with the policy to emit sensor values (enricher policies). 
-
-Entities can have zero or more ``Policy`` instances attached to them.
-
-<a name="writing-policies"></a>
-Writing Policies
-----------------
-
-### Sample Policy
-
-<!---
-TODO
--->
-
-*This section is not complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
-
-### Best Practice
-
-The following recommendations should be considered when designing policies:
-	
-#### Management should take place as "low" as possible in the hierarchy
-*	place management responsibility in policies at the entity, as much as possible ideally management should take run as a policy on the relevant entity
-
-*	place escalated management responsibility at the parent entity. Where this is impractical, perhaps because two aspects of an entity are best handled in two different places, ensure that the separation of responsibilities is documented and there is a group membership relationship between secondary/aspect managers.
-
-
-#### Policies should be small and composable
-<!-- 
-TODO Requires Content
--->
-
-e.g. one policy which takes a sensor and emits a different, enriched sensor, and a second policy which responds to the enriched sensor of the first 	(e.g. a policy detects a process is maxed out and emits a TOO_HOT sensor; a second policy responds to this by scaling up the VM where it is running, requesting more CPU)
-#### Where a policy cannot resolve a situation at an entity, the issue should be escalated to a manager with a compatible policy.
-
-Typically escalation will go to the entity parent, and then cascade up.
-e.g. if the earlier VM CPU cannot be increased, the TOO_HOT event may go to the parent, a cluster entity, which attempts to balance. If the cluster cannot balance, then to another policy which attempts to scale out the cluster, and should the cluster be unable to scale, to a third policy which emits TOO_HOT for the cluster.
-	
-#### Management escalation should be carefully designed so that policies are not incompatible
-
-Order policies carefully, and mark sensors as "handled" (or potentially "swallow" them locally), so that subsequent policies and parent entities do not take superfluous (or contradictory) corrective action.
-      
-
-For this release, some of the mechanisms for implementing the above practices are still being developed.
-
-### Implementation Classes
-
-*This section is not complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
-
-- extend ``AbstractPolicy``, or override an existing policy
-
-
-<a name="off-the-shelf-policies"></a>
-Off-the-Shelf Policies
-----------------------
-
-Policies are highly reusable as their inputs, thresholds and targets are customizable.
-
-### Management Policies
-- Resizer Policy
-   
-   Increases or decreases the size of a Resizable entity based on an aggregate sensor value, the current size of the entity, and customized high/low watermarks.
-
-   A Resizer policy can take any sensor as a metric, have its watermarks tuned live, and target any resizable entity - be it an application server managing how many instances it handles, or a tier managing global capacity.
-
-   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.
-  
-<!---
-TODO - list some
-TODO - describe how they can be customised (briefly mention sensors)
--->
-
-
-###  Enricher Policies
-
-*	Delta
-
-	Converts absolute sensor values into a delta.
-	
-
-*	Time-weighted Delta
-
-	Converts absolute sensor values into a delta/second.
-	
-*	Rolling Mean
-
-	Converts the last *N* sensor values into a mean.
-	
-*	Rolling Time-window Mean
-
-	Converts the last *N* seconds of sensor values into a weighted mean.
-
-*	Custom Aggregating
-
-	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. 
-
-<a name="implementing-policies"></a>
-Implementing Policies
----------------------
-
-<!---
-TODO
--->
-
-*This section is not yet complete. Feel free to [fork]({{site.path.guide}}/dev/code) the docs and lend a hand.*
-
-Please see the class* ``brooklyn.policy.Policy`` *and implementations.
-

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/topology-dependencies-management-policies.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/topology-dependencies-management-policies.md b/docs/guide/java/topology-dependencies-management-policies.md
new file mode 100644
index 0000000..8039d2c
--- /dev/null
+++ b/docs/guide/java/topology-dependencies-management-policies.md
@@ -0,0 +1,69 @@
+---
+layout: guide-normal
+title: Topology, Dependencies, and Management Policies
+title_in_menu: Topology, Dependencies, and Management Policies
+--- 
+Of course in the real world, application deployments are more interesting;
+they do things and need configuration.  For instance you might need to:
+
+* specify a WAR file
+* initialize the database
+* tell the webapp servers where to find the database
+
+Let's show how these are done using Brooklyn.
+We assume the WAR file and the database init script are accessible
+on the classpath, but a range of URL formats is supported.
+The "dependent inter-process configuration" -- giving the database's URL
+to the webapps -- we'll do here with a JVM system property,
+but you're free to use any mechanism you wish.
+
+Under the covers, ``attributeWhenReady`` is monitoring a sensor from MySQL
+and generating a string to pass to the webapp software processes; ``formatString``
+is a similar utility that returns a string once all of its parts have been resolved.
+Due to the use of futures, the Brooklyn webapp entities will automatically
+block "at the last moment" when the value is needed
+(but after e.g. the VMs have been provisioned, to speed things up).
+
+{% highlight java %}
+public class ClusterWebServerDatabaseSample extends AbstractApplication {
+    @Override
+    public void init() {
+        MySqlNode mysql = addChild(EntitySpec.create(MySqlNode.class)
+                .configure(MySqlNode.CREATION_SCRIPT_URL, "classpath://visitors-database-setup.sql"));
+        
+        ControlledDynamicWebAppCluster web = addChild(EntitySpec.create(ControlledDynamicWebAppCluster.class)
+                .configure("memberSpec", EntitySpec.create(JBoss7Server.class)
+                        .configure("httpPort", "8080+")
+                        .configure("war", WAR_PATH)
+                        .configure(JavaEntityMethods.javaSysProp("brooklyn.example.db.url"), 
+                                formatString("jdbc:%s%s?user=%s\\&password=%s", 
+                                        attributeWhenReady(mysql, MySqlNode.MYSQL_URL), DB_TABLE, DB_USERNAME, DB_PASSWORD))));
+    }
+}
+{% endhighlight %}
+
+We now see our app at the Nginx URL:
+
+[![Our Web App]({{ page.url_basedir }}wt-deployed-application-700.png "Screenshot of our Web App")](wt-deployed-application.png) 
+
+Finally, we'll bring in some active management: we're going to monitor requests per second,
+and scale out if this exceeds 100 up to a maximum of 5 servers.
+This is a naively simple policy, but it shows Brooklyn's real metier,
+running management policies for applications whose topology it knows. 
+
+{% highlight java %}
+        web.getCluster().addPolicy(AutoScalerPolicy.builder().
+                        metric(DynamicWebAppCluster.AVERAGE_REQUESTS_PER_SECOND).
+                        sizeRange(1, 5).
+                        metricRange(10, 100).
+                        build());
+{% endhighlight %}
+        
+*Policies* in Brooklyn typically subscribe to sensors,  perform some computation, and if necessary invoke effectors on entities.  This is where the ability to group entities
+becomes very useful -- policies can be attached to group entities, and groups themselves can be hierarchical. It's also handy that often Brooklyn creates the entities,
+so it knows what the hierarchy is.
+
+Under the covers, this ``AutoScalerPolicy`` attaches to any ``Resizable`` entity (exposing a ``resize`` effector), and monitors a specified sensor (or function) attempting to keep it within healthy limits. A separate policy operates at the ``Controlled`` cluster to ensure the load-balancer is updated as the pool of web servers expands and contracts.
+
+Fire up a JMeter session (or other load testing tool) and blast the Nginx address. The auto-scaler policy will scale up the cluster.
+

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/_java_walkthrough_p1.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/_java_walkthrough_p1.md b/docs/guide/java/walkthrough/_java_walkthrough_p1.md
deleted file mode 100644
index 3342784..0000000
--- a/docs/guide/java/walkthrough/_java_walkthrough_p1.md
+++ /dev/null
@@ -1,238 +0,0 @@
-{% include fields.md %}
-
-{% comment %} explicit rewrite_paths call needed since this is an included file {% endcomment %}
-{% rewrite_paths %}
-
-## Intro
-
-Brooklyn makes it easy to describe the structure and management of sophisticated distributed applications, 
-and then it makes it easy to launch them in a cloud, with on-going automated management.
-
-This walkthrough will set up a sample application which you can use as foundation for creating your own applications.
-
-The sample application is a three tier web service, composed of:
-
-* an Nginx load-balancer
-* a cluster of JBoss appservers
-* a MySQL database
-
-
-## Download the Sample Project
-
-If you'd like to follow these steps on your machine, you can use Maven to 
-download the Brooklyn quickstart archetype and setup a `brooklyn-sample` directory and project. 
-Maven will automatically download Brooklyn and all dependencies.
-You can of course follow this walkthrough without installing it on your machine ... yet!
-
-{% if SNAPSHOT %}
-
-{% highlight bash %}
-$ export BROOKLYN_VERSION=0.7.0-SNAPSHOT
-$ mvn archetype:generate \
-    -DarchetypeGroupId=io.brooklyn \
-    -DarchetypeArtifactId=brooklyn-archetype-quickstart \
-    -DarchetypeVersion=${BROOKLYN_VERSION} \
-    -DarchetypeCatalog=https://oss.sonatype.org/content/repositories/snapshots/archetype-catalog.xml \
-    -DgroupId=com.acme.sample \
-    -DartifactId=brooklyn-sample \
-    -Dversion=0.1.0-SNAPSHOT \
-    -Dpackage=com.acme.sample.brooklyn \
-    --batch-mode
-$ cd brooklyn-sample
-{% endhighlight %}
-
-*Note*: As this is a snapshot version of Brooklyn, the code above includes a `-DarchetypeCatalog` specification.
-This can be omitted for release versions, or if you already have a local `mvn install` of Brooklyn installed as described [here]({{site.path.guide}}/dev/code/index.html).
-
-{% else %}
-
-{% highlight bash %}
-$ export BROOKLYN_VERSION=0.7.0-SNAPSHOT
-$ mvn archetype:generate \
-    -DarchetypeGroupId=io.brooklyn \
-    -DarchetypeArtifactId=brooklyn-archetype-quickstart \
-    -DarchetypeVersion=${BROOKLYN_VERSION} \
-    -DgroupId=com.acme.sample \
-    -DartifactId=brooklyn-sample \
-    -Dversion=0.1.0-SNAPSHOT \
-    -Dpackage=com.acme.sample.brooklyn
-$ cd brooklyn-sample
-{% endhighlight %}
-
-{% endif %}
-
-## Define your Application Blueprint
-
-An application blueprint is defined as a Java class, as follows:
-
-{% highlight java %}
-public class ClusterWebServerDatabaseSample extends AbstractApplication {
-    @Override
-    public void init() {
-        MySqlNode mysql = addChild(EntitySpec.create(MySqlNode.class));
-        ControlledDynamicWebAppCluster web = addChild(EntitySpec.create(ControlledDynamicWebAppCluster.class));
-    }
-}
-{% endhighlight %}
-
-The file `ClusterWebServerDatabaseSample.java` in `src/main/java/com/acme/sample/brooklyn/sample/app/` 
-provides a template to follow.
-
-
-## Deploying the Application
-
-If you have not already done so, follow the section in the 
-[Getting Started Guide]({{site.path.guide}}/use/guide/quickstart/index.html) to create a `brooklyn.properties` 
-file containing credentials for your preferred cloud provider. 
-
-To launch this application, build the project and run the `start.sh` script in the resulting assembly:
-
-{% highlight bash %}
-$ mvn clean assembly:assembly
-
-$ cd target/brooklyn-sample-0.1.0-SNAPSHOT-dist/brooklyn-sample-0.1.0-SNAPSHOT/
-
-$ ./start.sh launch \
-    --app com.acme.sample.brooklyn.sample.app.ClusterWebServerDatabaseSample \
-    --location jclouds:aws-ec2:eu-west-1
-{% endhighlight %}
-
-(Amazon is used in this walkthrough, but lots of targets are supported,
-including `--location localhost`, fixed IP addresses, and 
-everything supported by [jclouds](http://jclouds.org), from OpenStack to Google Compute.)
-
-Your console will inform you that it has started a Brooklyn console at [http://localhost:8081](http://localhost:8081)
-
-[![Web Console]({{ page.url_basedir }}wt-starting-700.png "Web Console")](wt-starting.png) 
-
-The management console provides a view on to the entities that launched,
-including the hierarchy (appservers grouped into a cluster) and their locations. 
-
-Brooklyn collects information from these entities ("sensors"), 
-aggregates these for clusters and other groups (using "enrichers"),
-and exposes operations ("effectors") that can be performed on entities.
-
-[![Web Console Details]({{ page.url_basedir }}wt-tree-jboss-sensors-700.png "Web Console Details")](wt-tree-jboss-sensors.png) 
-
-
-## Topology, Dependencies, and Management Policies
-
-Of course in the real world, application deployments are more interesting;
-they do things and need configuration.  For instance you might need to:
-
-* specify a WAR file
-* initialize the database
-* tell the webapp servers where to find the database
-
-Let's show how these are done using Brooklyn.
-We assume the WAR file and the database init script are accessible
-on the classpath, but a range of URL formats is supported.
-The "dependent inter-process configuration" -- giving the database's URL
-to the webapps -- we'll do here with a JVM system property,
-but you're free to use any mechanism you wish.
-
-Under the covers, ``attributeWhenReady`` is monitoring a sensor from MySQL
-and generating a string to pass to the webapp software processes; ``formatString``
-is a similar utility that returns a string once all of its parts have been resolved.
-Due to the use of futures, the Brooklyn webapp entities will automatically
-block "at the last moment" when the value is needed
-(but after e.g. the VMs have been provisioned, to speed things up).
-
-{% highlight java %}
-public class ClusterWebServerDatabaseSample extends AbstractApplication {
-    @Override
-    public void init() {
-        MySqlNode mysql = addChild(EntitySpec.create(MySqlNode.class)
-                .configure(MySqlNode.CREATION_SCRIPT_URL, "classpath://visitors-database-setup.sql"));
-        
-        ControlledDynamicWebAppCluster web = addChild(EntitySpec.create(ControlledDynamicWebAppCluster.class)
-                .configure("memberSpec", EntitySpec.create(JBoss7Server.class)
-                        .configure("httpPort", "8080+")
-                        .configure("war", WAR_PATH)
-                        .configure(JavaEntityMethods.javaSysProp("brooklyn.example.db.url"), 
-                                formatString("jdbc:%s%s?user=%s\\&password=%s", 
-                                        attributeWhenReady(mysql, MySqlNode.MYSQL_URL), DB_TABLE, DB_USERNAME, DB_PASSWORD))));
-    }
-}
-{% endhighlight %}
-
-We now see our app at the Nginx URL:
-
-[![Our Web App]({{ page.url_basedir }}wt-deployed-application-700.png "Screenshot of our Web App")](wt-deployed-application.png) 
-
-Finally, we'll bring in some active management: we're going to monitor requests per second,
-and scale out if this exceeds 100 up to a maximum of 5 servers.
-This is a naively simple policy, but it shows Brooklyn's real metier,
-running management policies for applications whose topology it knows. 
-
-{% highlight java %}
-        web.getCluster().addPolicy(AutoScalerPolicy.builder().
-                        metric(DynamicWebAppCluster.AVERAGE_REQUESTS_PER_SECOND).
-                        sizeRange(1, 5).
-                        metricRange(10, 100).
-                        build());
-{% endhighlight %}
-        
-*Policies* in Brooklyn typically subscribe to sensors,  perform some computation, and if necessary invoke effectors on entities.  This is where the ability to group entities
-becomes very useful -- policies can be attached to group entities, and groups themselves can be hierarchical. It's also handy that often Brooklyn creates the entities,
-so it knows what the hierarchy is.
-
-Under the covers, this ``AutoScalerPolicy`` attaches to any ``Resizable`` entity (exposing a ``resize`` effector), and monitors a specified sensor (or function) attempting to keep it within healthy limits. A separate policy operates at the ``Controlled`` cluster to ensure the load-balancer is updated as the pool of web servers expands and contracts.
-
-Fire up a JMeter session (or other load testing tool) and blast the Nginx address. The auto-scaler policy will scale up the cluster.
-
-## What Next?
- 
-In addition to the sample project created by the archetype, with its README and
-`assembly` build, you can find additional code related to this example included with Brooklyn as the ``simple-web-cluster`` example,
-described [in detail here]({{site.path.guide}}/use/examples/webcluster).
-
-For your applications, you might want to mix in other data stores, messaging systems, or on-line services including PaaS.
-Brooklyn supports some of these out-of-the-box, including a wide-range of tools which it can use Whirr to provision, such as Hadoop.
-But if you have something you don't see, 
-[let us know]({{site.path.guide}}/meta/contact.html) -- 
-we want to work with you to 
-[write a new entity]({{site.path.guide}}/dev/code/entity.html) or
-[policy]({{site.path.guide}}/dev/code/policy.html) 
-and [contribute it]({{site.path.guide}}/dev/how-to-contrib.html).
-
-
-<!--
-
-Alternatively you can just add a ``main`` method to the application class as follows:
-
-{% highlight java %}
-    public static void main(String[] argv) {
-        List<String> args = Lists.newArrayList(argv);
-        String port =  CommandLineUtil.getCommandLineOption(args, "--port", "8081+");
-        String location = CommandLineUtil.getCommandLineOption(args, "--location", DEFAULT_LOCATION);
-
-        BrooklynServerDetails server = BrooklynLauncher.newLauncher()
-                .webconsolePort(port)
-                .launch();
-
-        Location loc = server.getManagementContext().getLocationRegistry().resolve(location);
-
-        StartableApplication app = new WebClusterDatabaseExample()
-                .appDisplayName("Brooklyn WebApp Cluster with Database example")
-                .manage(server.getManagementContext());
-        
-        app.start(ImmutableList.of(loc));
-        
-        Entities.dumpInfo(app);
-    }
-{% endhighlight %}
-
-Compile and run this with the [``brooklyn-all`` jar]({{site.path.guide}}/start/download.html) on the classpath,
-pointing at your favourite WAR on your filesystem. 
-(If the ``import`` packages aren't picked up correctly,
-you can cheat by looking at [the file in Github](https://github.com/apache/incubator-brooklyn/blob/master/examples/simple-web-cluster/src/main/java/brooklyn/demo/WebClusterDatabaseExample.java);
-and you'll find a sample WAR which uses the database as configured above 
-[here](https://http://ccweb.cloudsoftcorp.com/maven/libs-snapshot-local/io/brooklyn/).)
- TODO example webapp url 
- 
-If you want to adventure beyond ``localhost`` (the default),
-simply supply the your favourite cloud (e.g. ``aws-ec2:eu-west-1``)
-with credentials set up as described [here]({{ site.path.guide }}/use/guide/management/index.html#startup-config).
-
--->

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/index.md
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/index.md b/docs/guide/java/walkthrough/index.md
deleted file mode 100644
index 1bf57cb..0000000
--- a/docs/guide/java/walkthrough/index.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-layout: guide-normal
-title: Java Walkthrough
-title_in_menu: Walkthrough
----
-
-{% readj _java_walkthrough_p1.md %}

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/wt-deployed-application-700.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/wt-deployed-application-700.png b/docs/guide/java/walkthrough/wt-deployed-application-700.png
deleted file mode 100644
index 7ef90d9..0000000
Binary files a/docs/guide/java/walkthrough/wt-deployed-application-700.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/wt-deployed-application.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/wt-deployed-application.png b/docs/guide/java/walkthrough/wt-deployed-application.png
deleted file mode 100644
index 751402e..0000000
Binary files a/docs/guide/java/walkthrough/wt-deployed-application.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/wt-starting-700.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/wt-starting-700.png b/docs/guide/java/walkthrough/wt-starting-700.png
deleted file mode 100644
index c87a539..0000000
Binary files a/docs/guide/java/walkthrough/wt-starting-700.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/wt-starting.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/wt-starting.png b/docs/guide/java/walkthrough/wt-starting.png
deleted file mode 100644
index 970805f..0000000
Binary files a/docs/guide/java/walkthrough/wt-starting.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/wt-tree-jboss-sensors-700.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/wt-tree-jboss-sensors-700.png b/docs/guide/java/walkthrough/wt-tree-jboss-sensors-700.png
deleted file mode 100644
index 3dfc7f2..0000000
Binary files a/docs/guide/java/walkthrough/wt-tree-jboss-sensors-700.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/walkthrough/wt-tree-jboss-sensors.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/walkthrough/wt-tree-jboss-sensors.png b/docs/guide/java/walkthrough/wt-tree-jboss-sensors.png
deleted file mode 100644
index 4c44ea9..0000000
Binary files a/docs/guide/java/walkthrough/wt-tree-jboss-sensors.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/wt-deployed-application-700.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/wt-deployed-application-700.png b/docs/guide/java/wt-deployed-application-700.png
new file mode 100644
index 0000000..7ef90d9
Binary files /dev/null and b/docs/guide/java/wt-deployed-application-700.png differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/wt-deployed-application.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/wt-deployed-application.png b/docs/guide/java/wt-deployed-application.png
new file mode 100644
index 0000000..751402e
Binary files /dev/null and b/docs/guide/java/wt-deployed-application.png differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/wt-starting-700.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/wt-starting-700.png b/docs/guide/java/wt-starting-700.png
new file mode 100644
index 0000000..c87a539
Binary files /dev/null and b/docs/guide/java/wt-starting-700.png differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/wt-starting.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/wt-starting.png b/docs/guide/java/wt-starting.png
new file mode 100644
index 0000000..970805f
Binary files /dev/null and b/docs/guide/java/wt-starting.png differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/wt-tree-jboss-sensors-700.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/wt-tree-jboss-sensors-700.png b/docs/guide/java/wt-tree-jboss-sensors-700.png
new file mode 100644
index 0000000..3dfc7f2
Binary files /dev/null and b/docs/guide/java/wt-tree-jboss-sensors-700.png differ

http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/a71a7df8/docs/guide/java/wt-tree-jboss-sensors.png
----------------------------------------------------------------------
diff --git a/docs/guide/java/wt-tree-jboss-sensors.png b/docs/guide/java/wt-tree-jboss-sensors.png
new file mode 100644
index 0000000..4c44ea9
Binary files /dev/null and b/docs/guide/java/wt-tree-jboss-sensors.png differ


Mime
View raw message