In this post I’ll cover how my HyperJaxb3 based RESTful web-service gets built, tested and deployed.
What did I want the project’s build to demonstrate?
Fully automated end-to-end build, test and deployment with integration testing of JEE6 applications.
I chose Maven to handle the build because it’s well supported and perfect for this type of requirement. By choosing Maven I get the consistency of a prescribed build lifecycle and fully automated dependency management.
I also wanted an opportunity to use Glassfish V3 and JEE6. I prefer Glassfish to JBoss these days because of its great Admin console.
What frameworks does the project use?
The project is a JEE6 WAR packaged web-application containing stateless EJB’s (which is a new feature of JEE6). The jax-rs implementation I’m using is Jersey from Sun which also takes care of marshalling data in either JSON or XML format into Java objects and vice versa. The JPA implementation is Eclipselink, previously known as Oracle Toplink. The application depends on the default datasource provided in Glassfish which is based on the JavaDB database.
What happens during the Maven build?
In Maven I use the ‘verify‘ goal which sits towards the end of the Maven build lifecycle. This causes the following steps to occur during each build…
- Generate sources. The HyperJaxb3 Maven Plugin picks up my ‘Item.xsd’ in the generate-sources stage and creates a set of Java objects that are annotated as using both JPA for persistence and JAXB for XML marshalling. It also generates the container persistence configuration file used by Glassfish.
- Compile. The code is then compiled as usual using the generated sources from step 1.
- Test. The JUnit tests are then run using Mockito to mock out the JPA framework and the EJB used for CRUD operations.
- Package. The application is then packaged into a WAR archive.
- Start-domain. The Glassfish Maven Plugin starts an embedded Glassfish V3 instance using a customised configuration.
- The WAR archive is then deployed to the embedded server instance.
- Integration test. The SoapUI Maven Plugin then starts a SoapUI v3 test that tests the REST interface and ensures all the integrated components are working correctly together.
- The application WAR is undeployed.
- Stop-domain. Finally, the embedded Glassfish instance is shut-down.
This process ensures that everything can be built, tested, deployed and integration tested in one fully automated process. If this were handled by a CI server like Hudson or Mike, then you would get a full end-to-end test every time the build is triggered.
I enjoyed putting this project together and figured this was a pretty useful build process that I could use again and again. What do you think? Send me a comment.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
