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.
1 of 1 people found this helpful
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.
Actually we have two different types here.
The WebLogic containers, which does not depend on weblogic binaries, are compiled by the CI server.
The WebSphere containers, which depend on websphere binaries, are only available in source form as of now.
Well, that matched my expectations for the test suite.