Add descriptions of samples to README

README.adoc

@@ -2,7 +2,7 @@
 
 image::https://travis-ci.org/spring-cloud/spring-cloud-streams.svg?branch=master[Build Status, link=https://travis-ci.org/spring-cloud/spring-cloud-streams]
 
-This project allows a user to develop and run messaging microservices using Spring Integration and run them locally, or in the cloud, or even on Spring XD. It also allows a user to develop and run an XD module locally. Just create `MessageChannels` "input" and/or "output" and add `@EnableChannelBinding` and run your app as a Spring Boot app (single application context).  You just need to connect to the physical broker for the bus, which is automatic if the relevant bus implementation is available on the classpath. The sample uses Redis.
+This project allows a user to develop and run messaging microservices using Spring Integration and run them locally, or in the cloud, or even on Spring XD. Just create `MessageChannels` "input" and/or "output" and add `@EnableChannelBinding` and run your app as a Spring Boot app (single application context).  You just need to connect to the physical broker for the bus, which is automatic if the relevant bus implementation is available on the classpath. The sample uses Redis.
 
 Here's a sample source module (output channel only):
 
@@ -56,7 +56,25 @@ To be deployable as an XD module in a "traditional" way you need `/config/*.prop
 
 A module can have multiple input or output channels. Instead of just one channel named "input" or "output" you can add multiple `MessageChannel` beans named `input.*` or `output.*` and the names are converted to external channel names on the broker. The external channel names are the `spring.cloud.streams.[input|output]ChannelName` plus the `MessageChannel` bean name, period separated. In addition, the bean name can be `input.[queue|topic|tap]:*` or `output.[queue|topic]:*` (i.e. with a channel type as a colon-separated prefix), and the semantics of the external bus channel changes accordingly (a tap is like a topic). For example, you can have two `MessageChannels` called "output" and "output.topic:foo" in a module with `outputChannelName=bar`, and the result is 2 external channels called "bar" and "topic:foo.bar".
 
-== XD Module Samples
+== Samples
+
+There are several samples, all running on the redis transport (so you need redis running locally to test them).
+
+=== Vanilla Module Samples
+
+NOTE: The main set of samples are "vanilla" in the sense that they are not deployable as XD modules by the current generation (1.x) of XD. You can still interact with an XD system using the appropriate naming convention for input and output channel names (`<stream>.<index>` format).
+
+* `source` is a Java config version of the classic "timer" module from Spring XD. It has a "fixedDelay" option (in milliseconds) for the period between emitting messages.
+
+* `sink` is a Java config version of the classic "log" module from Spring XD. It has no options (but some could easily be added), and just logs incoming messages at INFO level.
+
+* `transform` is a simple pass through logging transformer (just logs the incoming message and passes it on).
+
+* `double` is a combination of 2 modules defined locally (a source and a sink, so the whole app is self contained).
+
+* `extended` is a multi-module mashup of `source | transform | transform | sink`, where the modules are defined in the other samples and referred to in this app just as dependencies.
+
+=== XD Module Samples
 
 There are several samples, all running on the redis transport (so you need redis running locally to test them):
 

docs/README.adoc

@@ -1,22 +0,0 @@
-// Do not edit this file (e.g. go instead to src/main/asciidoc)
-
-
-This project provides Netflix OSS integrations for Spring Boot apps through autoconfiguration
-and binding to the Spring Environment and other Spring programming model idioms. With a few
-simple annotations you can quickly enable and configure the common patterns inside your
-application and build large distributed systems with battle-tested Netflix components. The 
-patterns provided include Service Discovery (Eureka), Circuit Breaker (Hystrix), 
-Intelligent Routing (Zuul) and Client Side Load Balancing (Ribbon).
-
-
-== Features
-
-* Service Discovery: Eureka instances can be registered and clients can discover the instances using Spring-managed beans
-* Service Discovery: an embedded Eureka server can be created with declarative Java configuration
-* Circuit Breaker: Hystrix clients can be built with a simple annotation-driven method decorator
-* Circuit Breaker: embedded Hystrix dashboard with declarative Java configuration
-* Declarative REST Client: Feign creates a dynamic implementation of an interface decorated with JAX-RS or Spring MVC annotations
-* Client Side Load Balancer: Ribbon
-* External Configuration: a bridge from the Spring Environment to Archaius (enables native configuration of Netflix components using Spring Boot conventions )
-* Router and Filter: automatic registration of Zuul filters, and a simple convention over configuration approach to reverse proxy creation
-

docs/src/main/asciidoc/intro.adoc

@@ -1,4 +1,4 @@
-This project allows a user to develop and run messaging microservices using Spring Integration and run them locally, or in the cloud, or even on Spring XD. It also allows a user to develop and run an XD module locally. Just create `MessageChannels` "input" and/or "output" and add `@EnableChannelBinding` and run your app as a Spring Boot app (single application context).  You just need to connect to the physical broker for the bus, which is automatic if the relevant bus implementation is available on the classpath. The sample uses Redis.
+This project allows a user to develop and run messaging microservices using Spring Integration and run them locally, or in the cloud, or even on Spring XD. Just create `MessageChannels` "input" and/or "output" and add `@EnableChannelBinding` and run your app as a Spring Boot app (single application context).  You just need to connect to the physical broker for the bus, which is automatic if the relevant bus implementation is available on the classpath. The sample uses Redis.
 
 Here's a sample source module (output channel only):
 
@@ -52,7 +52,25 @@ To be deployable as an XD module in a "traditional" way you need `/config/*.prop
 
 A module can have multiple input or output channels. Instead of just one channel named "input" or "output" you can add multiple `MessageChannel` beans named `input.*` or `output.*` and the names are converted to external channel names on the broker. The external channel names are the `spring.cloud.streams.[input|output]ChannelName` plus the `MessageChannel` bean name, period separated. In addition, the bean name can be `input.[queue|topic|tap]:*` or `output.[queue|topic]:*` (i.e. with a channel type as a colon-separated prefix), and the semantics of the external bus channel changes accordingly (a tap is like a topic). For example, you can have two `MessageChannels` called "output" and "output.topic:foo" in a module with `outputChannelName=bar`, and the result is 2 external channels called "bar" and "topic:foo.bar".
 
-== XD Module Samples
+== Samples
+
+There are several samples, all running on the redis transport (so you need redis running locally to test them).
+
+=== Vanilla Module Samples
+
+NOTE: The main set of samples are "vanilla" in the sense that they are not deployable as XD modules by the current generation (1.x) of XD. You can still interact with an XD system using the appropriate naming convention for input and output channel names (`<stream>.<index>` format).
+
+* `source` is a Java config version of the classic "timer" module from Spring XD. It has a "fixedDelay" option (in milliseconds) for the period between emitting messages.
+
+* `sink` is a Java config version of the classic "log" module from Spring XD. It has no options (but some could easily be added), and just logs incoming messages at INFO level.
+
+* `transform` is a simple pass through logging transformer (just logs the incoming message and passes it on).
+
+* `double` is a combination of 2 modules defined locally (a source and a sink, so the whole app is self contained).
+
+* `extended` is a multi-module mashup of `source | transform | transform | sink`, where the modules are defined in the other samples and referred to in this app just as dependencies.
+
+=== XD Module Samples
 
 There are several samples, all running on the redis transport (so you need redis running locally to test them):