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.