I'm interested in implementing and contributing support for a proprietary container (Java EE 5 certified). Talked to ALR and we came to the interesting question of distribution.
I would like to know what you guys think. Here's my take on this:
The Arquillian adaptor for the container will be under ASL 2.0, so no problems there. But what about tests regarding that container? The container binaries are not freely distributable, so pretty much nobody would be able to run them.
I think that in general, this is an important topic that should be discussed in order to clear the way for other containers as well.
We have a similar situation with the WebLogic and WebSphere container integrations. The CI server at CloudBees does not run the unit & integration tests for these containers; it merely builds them. Also, none of these integrations use the APIs of the containers currently, and hence do not need these containers to be installed in the CI server. Correctness of the builds is left to the module leads(?).
End-users however would have their own WLS/WAS installations to use these integrations. So, if you're writing an integration for a proprietary container, you would have to ensure that it builds without the container libraries i.e. no compile-time dependencies. Use reflection, ProcessBuilder etc. to depend on the container APIs and executables at runtime.
I guess Aslak could confirm that this is the expectation from a integration with a proprietary container requiring a commercial license.
As Vineet said, we currently have support for a couple of proprietary containers, where the CI server only build the binaries and assure they can compile. 'Automatic' testing is left to the Module Lead (the one with the proprietary binaraies available).
We are in the process of investigating how/if we can setup automation with these containers as well.