Tooling change for test mixin modularization
Now that mixins have been split out into individual modules, every SY application will have to specifically identify which mixins will be used for test support. At a low-level, this basically means that an application which used to use the JCA, Naming, and CDI mixins before could get all dependencies with this:
<dependency> <groupId>org.switchyard</groupId> <artifactId>switchyard-test</artifactId> <scope>test</scope> </dependency>
The above would bring the entire testing world in before modularization. Now that the test stuff is split up, we need to add the following dependencies to the application pom.xml :
<dependency> <groupId>org.switchyard.components</groupId> <artifactId>switchyard-component-test-mixin-cdi</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.switchyard.components</groupId> <artifactId>switchyard-component-test-mixin-hornetq</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.switchyard.components</groupId> <artifactId>switchyard-component-test-mixin-jca</artifactId> <scope>test</scope> </dependency>
Rob and I had a brief chat on IRC about the right way to do this from a user perspective. One option is to simply add these dependencies as a user enables specific SY capabilities. Today, if a user selects the Bean service capability, we add a dependency on the bean component. We could also add a test-scoped dependency on the CDI MixIn as well. This seems user friendly, although there's not always a direct correlation between a mixin and a component. We also don't know if the user plans on testing (although I hope they do!). Another option is to have a similar checkbox style view for test capabilities as we have for service/gateway capabilities today. This gives the user independent control over which MixIn dependencies are included in their project.
I think we should actually do both. I suggest we start with the checkbox style because I think that's mandatory to give the user proper control over project dependencies. Then we implement the "smart" dependency option that's correlated to a user's service/gateway capability choices.
BTW, I think we should always keep the switchyard-test dependency around as we do today. I know that the other mixins will pull this in transitively, but it can be used without any mixins and I don't see a lot of overhead in keeping it around.
