I started off with a handful of inherited projects loosely cobbled together with no declarative dependency management (old style - directory of jars in each project, copied into one big mess for deployment).
My initial task was to investigate using the existing system to expose access to the same data sources using REST, without breaking the existing SOAP implementation.
I muddled around for a couple of days and was reasonably happy with what Jersey was able to produce based on JAX-RS, but I wasn't satisfied with the amount of manual steps in the build process.
As a stop-gap measure I cobbled together some ant magic for making the downwind projects aware of their upwind dependencies, so any changes would be detected during a rebuild and a completely up to date WAR would be produced from a single command.
A few weeks later the client's main supplier disappeared over the Christmas break, as I was stuck with a number of unanswered questions I took the opportunity to make the external dependencies of each project explicit, and to re-enable the SOAP functionality as part of the webapp.
Axis2 doesn't lend itself well to being deployed as part of another application, it is more designed for flexibility of deploying services within it, rather than it being deployed into something else.
After a bit of experimentation I had axis2 SOAP services sitting alongside my REST services.
When I came to untangle the combined dependencies of axis2 and the project I found a potentially nasty clash of versions of the commons-httpclient jar. A bit of Googling and reading of Jira posts gave me a fair indication that it wasn't likely to change in axis2 any time soon.
So, I tried something a little drastic - replacing axis2 with CXF.
CXF is more suited for our purposes and by happy coincidence is already integrating with Spring 3.
And we all lived happily ever after.
