Building OpenESB v2 Composite Applications with Maven

In my current project I have set up a continuous integration environment consisting of Subversion, Maven, Nexus and Hudson and four servers (development, test, acceptance and production). The idea is to take away as much developer responsibilities concerning library and version management as possible, as well as facilitating an error prone mechanism to test and roll out your applications. One of the pitfalls I encountered was the lack of Maven support in NetBeans 6.7(.1) for JBI Modules and CASA projects. This article outlines the steps I took to be able to build and deploy Composite Applications to GlassFish/OpenESB v2 using Hudson.

The NetBeans build lifecycle

For building JBI Modules and CASA projects NetBeans heavily depends on Ant. For JBI Modules the build process is fairly simple. First several project specific variables are set using several properties files that are located in the nbproject directory within the project directory. Some of these properties are used to specify output file names and directories. However, use is made of a file called private.properties which can be found in the nbproject/private directory. This file specifies where NetBeans and the SOA modules are installed by the current user and this info is used to load several jar files that are needed while building the module. After loading these settings NetBeans specific Ant Tasks are ran to validate the project and to generate the needed catalog.xml and jbi.xml files. Finally, a jar is created by calling the Ant jar task.

For CASA projects the build process is slightly more complicated. First similar project properties as for JBI Modules are loaded. Then, the jar file of each JBI Module that is included in the Composite Application is expanded and the files contained in it are copied over to a JBI Module specific directory structure for later use. Then the NetBeans specific jbi-build-service-assembly Ant Task is called. Basically this task builds the needed jbi.xml file for this Composite Application and puts all needed jar files together. In other words, this is the heart of the Composite Application build process. Finally, some cleaning up is done and a zip file containing the Composite Application that can be deployed is created.

Moving to Maven

The fact that NetBeans uses NetBeans specific Ant Tasks makes it hard to entirely Mavenise the build lifecycle. To do that, one would probably have to take the NetBeans source and figure out what each Ant Task exactly does. Next, Java classes would have to be created to perform the duties of the Ant Tasks which then would have to be executed from Maven. Too much hassle if you ask me.

Instead, the Maven Antrun plugin would allow the reuse of the NetBeans specific Ant Tasks. So, the first thing to do is to create pom.xml files that execute the NetBeans Ant Tasks for JBI Modules and for Composite Applications. This didn’t prove to be very hard. I noticed that quite a lot of error checking is done from the Ant build scripts. Since my intention was to build and deploy Composite Applications from Hudson, I took the liberty to skip most of the checks assuming that the developers in my team would only check in project code that would at least build correctly. I know, this isn’t a very safe assumption and it needs looking into once we run into problems.

In order to manage both the JBI Modules and the Composite Application together from Maven you may want to create a parent project with a pom.xml file that contains the JBI Module project(s) and the Composite Application project as children. This way you can configure and execute the entire build lifecycle for each Composite Application in one go.

Issues when using Maven and Hudson

There are three things to keep in mind here. First, whenever a JBI Module is added to or removed from a Composite Application the Module will need to be manually added to or removed from the CASA pom.xml file. Fortunately this isn’t an operation that often is done while developing a Composite Application but it will need attention every time this is done!

The second and third things to keep in mind are kind of similar. Building JBI Modules and Composite Applications requires several NetBeans jars to be on the classpath. And deploying a Composite Application using the specific NetBeans Ant Tasks requires a valid NetBeans user directory. Both need valid private.properties files. When using Maven from your local development project this shouldn’t be much of a problem since these files are generated when a project is first opened in NetBeans. However, when someone or something (like Hudson) does a fresh checkout of the project from a versioning system (in our case Subversion), the build would fail because the necessary info is missing to locate the jars containing the NetBeans specific Ant Tasks etc.

Fixing the private.properties issues

There are several ways to fix the issues that arise from missing private.properties files. One way would be to specify the necessary properties in a Maven profile. This would still require a valid NetBeans location, however, and would require the Hudson “user” to have started NetBeans at least once so a private NetBeans user directory is present.

Another solution would be to try and get rid of the dependency on NetBeans. This requires two things to be taken care of. First, all needed NetBeans libraries should be present for Maven. Second, deployment to OpenESB should be taken care of.

Making all needed NetBeans jars available to Maven isn’t a very difficult thing to do. One of the key features of Maven is library dependency management so let’s make use of it! All that needs be done is to specify the dependencies in the pom.xml files of the JBI Module(s) and the Composite Application, or more preferably in the parent pom.xml, and make sure the Maven compile classpath is passed on to Ant using the Maven Antrun plugin. As far as I have been able to find out, the NetBeans 6.7 jars are not available through any public Maven repository. Therefore I installed all needed 50 odd NetBeans jars into a local repository myself and went through the manual labor of installing these jar files into Nexus one by one. This pretty much resolved the classpath dependency on the private.propeties files.

As for deploying the CASA zip to OpenESB, there again are several options. A few Maven plugins for deploying to GlassFish (and therefore OpenESB) exist. However, none of these support the commands to manage Composite Applications on GlassFish/OpenESB. In the end I resorted to using the Antrun plugin to call the GlassFish asadmin command line tool to call the deploy-jbi-service-assembly command.

Calling that command provided me with one more challenge to overcome. One that apparently has been taken care of by the DeployServiceAssembly NetBeans Ant Task that I tried to replace. Whenever a Composite Application has been deployed already, the deploy-jbi-service-assembly command fails complaining that the Composite Application should be undeployed first. However, undeploying a Composite Application fails if it hasn’t been deployed before. Both failures will cause Maven to exit with an error. In other words, the first time a Composite Application needs to be deployed, it may not be undeployed first. Every consecutive deployment requires an undeployment first. This means that before the Composite Application can be deployed first a check should be done if an existing Composite Application should be undeployed. To my best of knowledge there is no easy way to do this with Maven.

Fortunately I decided to use the Antrun plugin to deploy the Composite Applications to OpenESB. Ant can make use of the ant-contrib library that allows for the possibility to execute additional tasks based on the outcome of a test. The test would be to execute the show-jbi-service-assembly asadmin command to check if the Composite Application already has been deployed before. This command returns a 0 (deployed) or 1 (not deployed). Using an construct one can then execute the shut-down-jbi-service-assembly and undeploy-jbi-service-assembly asadmin commands before executing the deploy-jbi-service-assembly asadmin command if the show-jbi-service-assembly asadmin command returns a 0.

Conclusion

Switching from Ant to Maven when it comes to NetBeans JBI Modules and Composite Applications isn’t impossible. But it takes quite some work before all works as you probably would like it to. Part of the work is getting rid of local NetBeans settings. Besides that, keeping your JBI Modules and Composite Applications Mavenized will take some effort. Once properly set up, it should be possible to use Hudson to build your Composite Applications and include them in your development cycle from your development to your test, acceptance and eventually production servers. That is well worth the effort if you ask me!