anchor.diff:  </dependency>
   ----
   
  -====== Multiple binders on the classpath
  -
  -When multiple binders are present on the classpath, the application must indicate what binder has to be used for the channel. Each binder configuration contains a `META-INF/spring.binders`, which is in fact a property file:
  +====== Multiple Binders on the Classpath
  +
  +When multiple binders are present on the classpath, the application must indicate which binder is to be used for each
  +channel binding. Each binder configuration contains a `META-INF/spring.binders`, which is a simple properties file:
   
   [source]
   ----
  
positive.code: org.springframework.cloud.stream.binder.rabbit.config.RabbitServiceAutoConfiguration
  ----
  
  Similar files exist for the other binder implementations (i.e. Kafka and Redis), and it is expected that custom binder implementations will provide them, too. The key represents an identifying name for the binder implementation, whereas the value is a comma-separated list of configuration classes that contain one and only one bean definition of the type `org.springframework.cloud.stream.binder.Binder`.
  
  Selecting the binder can be done globally by either using the `spring.cloud.stream.defaultBinder` property, e.g. `spring.cloud.stream.defaultBinder=redis`, or by individually configuring them on each channel.
  
  For instance, a processor module that reads from Rabbit and writes to Redis can specify the following configuration: `spring.cloud.stream.bindings.input.binder=rabbit`,`spring.cloud.stream.bindings.output.binder=redis`.
  
  ====== Connecting to multiple systems
  
  By default, binders share the Spring Boot autoconfiguration of the application module and create one instance of each binder found on the classpath. In scenarios where a module should connect to more than one broker of the same type, Spring Cloud Stream allows you to specify multiple binder configurations, with different environment settings. Please note that turning on explicit binder configuration will disable the default binder configuration process altogether, so all the binders in use must be included in the configuration.
  
  For example, this is the typical configuration for a processor that connects to two rabbit instances:
  
  [source,yml]
  ----
  
negative.code: [partintro]
  --
  This section goes into more detail about how you can work with Spring Cloud Stream. It covers topics
  such as creating and running stream applications.
  --
  
  === Introducing Spring Cloud Stream
  
  The Spring Cloud Stream project allows a user to develop and run messaging microservices using Spring Integration.
  Just add `@EnableBinding` and run your app as a Spring Boot app (single application context).
  Spring Cloud Stream applications connect to the physical broker through bindings, which link Spring Integration
  channels to physical broker destinations, for either input (consumer bindings) or output (producer bindings).
  The creation of the bindings, and therefore their broker-specific implementation is handled by a binder, which is
  another important abstraction of Spring Cloud Stream. Binders abstract out the broker-specific implementation details.
  In order to connect to a specific type of broker (e.g. Rabbit or Kafka) you just need to have the relevant binder
  implementation on the classpath.
  
  Here's a sample source app (output channel only):
  
  [source,java]
  ----
  @SpringBootApplication
  public class StreamApplication {
  
    public static void main(String[] args) {
      SpringApplication.run(StreamApplication.class, args);
    }
  }
  
  @EnableBinding(Source.class)
  public class TimerSource {
  
  