As I mentioned in the previous blog entry, the final goal was to develop a Maven-powered environment in which the deployable unit - in our case the EAR file - would be generated by a set of scripts starting from checking out versioned code from PVCS. I would lie if I tell you that I liked Maven at first sight. My initial feelings were anger and frustration as Maven-enabled RAD essentially diminished RAD to be just a fancy code editor - and nothing more. Gone were round-trip interactive development, and my productivity as a developer really suffered. Only by the end of the project I found out how to keep RAD effective and fully engaged and still be able to build using Maven. At the very end of the project I started to really appreciate the effectiveness of Maven as a build tool especially when it comes to building deployable units for different environments in a very uniform and reliable way. Its ability to manage versioned dependencies is just outstanding given the relative simplicity with which this is achieved.
Anyway, for regular Dynamic Web Projects the task would be trivial - Maven already has a plug-in to generate all deployable artifacts. But for Web projects with Web services there was nothing I could use because there were a number of generated artifacts which simply did not fit into Maven’s rigid default directory structure. I faced a task of developing a new Maven plug-in just for the tasks on hand (as long as I am mentioning this, you may guess that plug-in was successfully implemented, but read below to find out at what cost).
To assess the scope of the effort involved, let me just list the tasks accomplished.
Given: set of RAD projects fresh from PVCS each with Maven pom.xml. One specialized project had all WSDL and XSD files. Parent folder had pom.xml with our custom Maven Web services plug-in properties and configurations. Note that only scripts and libraries available with WAS 6.1 run-time are used for code generation. No part of RAD is used for Maven plug-in (in fact our customer uses AIX to run build scripts).
Below is the overview of custom plug-in functionality:
- For each WSDL in parent pom.xml run WSDL2Java script, create temporary folder structure with all Java and XML configuration files.
- For each generated webservices.xml go in and replace generated placeholder with actual servlet class name (this is because WSDL2Java script just does not do that by design).
- Combine all webservices.xml files together and create single webservices.xml to be put in the target project.
- Collect all mapping xml files and put them together in the target project.
- Collect all servlets names and classes names for each WSDL and put them as servlet/servlet-mapping entries in the Web Deployment Descriptor in the target project.
- Copy WSDL and XSD files into the target project WEB-INF/wsdl folder.
- Copy all generated Java sources and put them together with existing source code.
- Pass resulting project to the standard Maven Web project plug-in to be compiled and built.
At the end the Prolifics team had accomplished everything the client asked us to do. and we left the site with application up and running in production with no problems. The only thing they asked with amazement was: "How did you do that, guys?"
Vladimir Serebryany is a Senior Consultant at Prolifics with in-depth knowledge and broad hands-on experience with the J2EE environment as well as expertise in EJBs, Servlets, JSP and JSF. Excelling at migrations, Vladimir has over 9 years of experience with a wide range of complementary skills including WebSphere, WebSphere MQ, WebSphere Business Integration Message Broker, UNIX, C/C++, Java, HTML/ASP, JavaScript, and Visual Basic. He has served as team leader/senior developer roles in large, complex projects and configurations with clients in the financial, insurance and telecommunication industries - among others.
Posts
