spring-projects/spring-xd — pull request #1307 by ericbottard (2014-11-28 10:33:22+00:00)
Title: XD-2381: Decouple messagebus dependencies

This PR does the following:
* Create new gradle projects for each MessageBus implementation, as well as one for the supporting classes (e.g. AbstractMessageBus) named `spring-xd-messagebus-spi`
* Change the build system so that these projects are not on the runtime classpath of `dirt` anymore. Instead, a new task copies (the resulting jar + transitive deps - what's already on dirt) into `$XD_HOME/lib/messagebus/`
* Slightly change the spring application context files loading, removing the indirection that existed thru `message-bus.xml` which was a oneliner import.
* Create a dynamic ClassLoader given the value of `${XD_TRANSPORT}` that is used at the shared context level

This all works fine but has the following implications:
* The previous dynamic check of the `--transport` CLI option does not work anymore (as all implementations are not visible anymore). When we do work on the hadoop libs, a similar problem will arise. Below are the options, I'm in favor of option 2:
1. Somehow make that validation code aware of all the implementations
2. Drop usage of `--transport` and rely on ${XD_TRANSPORT} only (which is already what we do for distributed setup anyway)
* The tests for bus implementations (and other tests that do not create a true `*ServerApplication`) work because the bus projects, while not part of the `runtime` configuration, have been added as `testCompile`. I believe for the sake of cleanliness (and for providing a better sdk for bus implementors) that we should spin off some other projects (e.g. `spring-xd-messagebus-spi-testsupport`). Better covered as a separate PR though IMHO