I have made much more progress with the Websphere support for cargo. I am about to post another patch which currently provides the following features:
1. Websphere 5.x support at the moment only
2. Support for a local existing installation of websphere only (at this stage)
3. The ability to start, stop, deploy, start, stop, and undeploy applications (only EARs at this stage)
Some issues that I have had and am currently still experiencing (and may need some assistance with):
1. Websphere must be executed with the IBM JDK that is provided with it, thus I override the JRE executable used on the java task. This means that the maven/cargo don't necessarily
have to also run in the IBM JVM which I think is a good thing.
2. Getting websphere to start proved to be quite a challenge. After much trial and error I now have a working configuration, however I am not entirely sure how portable this code is and more
importantly I am not sure if this covers any other edge cases or the code is superfluous.
3. Websphere needs to be installed on the machine from which the plugin is executed, for both local and remote containers, as the ability to deploy/undeploy requires many libraries, dlls, etc
from the websphere home directory. This can still target any other independent server available remotely, albeit with added complexity (such as the file may need to be copied/scp'ed/ftp'ed to the
server first as deployment can only happen from a local mount point). This also poses some design questions as the remote container is much more like a local container, specifically with regards
to the configuration it requires (the home directory, the websphere home directory, etc.) What is the best design guidance here?
4. I currently only support EAR deployments as I not entirely sure if the Websphere JACL script I am using can be used on WAR applications. This still needs to be tested.
5. The EAR deployable had to be customised as well for Websphere as the install task requires the physical EAR to be installed, but all other tasks such as start, stop, and uninstall require the symbolic
name of the EAR. Hence, I have subclassed the EAR deployable and used the display-name of the ear from the application.xml file if it is available, otherwise I fall back to the default of using the ear
filename without the .ear suffx. This requires me to subclass EAR, but the name property is private and the parseName() method is private, which I need to both be protected.
The way forward:
1. Implement Remote Container functionality (your thoughts?)
2. Attempt to add support for WAR, EJB archives?
3. Clean up the code, there seems to still be a bit of duplication
4. Write tests, tests, and more tests?
5. Attempt support for Websphere 6.x
That being said I am currently using the cargo websphere plugin to deploy onto a container within my own environment succesfully.
I don't really have much time to work on this plugin at the moment, and any help for anyone would be appreciated. I hope that make this code available will atleast create a common platform to discuss
additions, enhancements, etc.
Lastly what steps need to be taken to obtain commit access as the process continues.