Setting up your application server with maven
In many cases there is no way to deploy an application without the need to setup your application before. In JBoss AS 7.x you may want to configure for example your database connection. Or you have to configure a security realm. Maybe you also want to adjust the SLSB pool… In any of these cases all developers in the team have to share a common or at least a similar configuration.
Often this information can be found in sporadically sent emails or on some wiki page. But what happens sometime after a release, when you have to check out a branch to fix some bug or to add a new feature? You will have to reconstruct the configuration that was valid for this branch. So why not add the configuration files to your version control system and together with the mere configuration files, a maven configuration that sets up the whole application server?
Let’s try to keep it simple and use only public available and commonly used plugins. First of all let’s add all versions that we will need in the following to the properties part of the pom.xml:
<properties>
<jboss.install.dir>${project.build.directory}/jboss</jboss.install.dir>
<jboss.version>7.2.0.Final</jboss.version>
<app.version>${project.version}</app.version>
<ojdbc.version>11.2.0.1.0</ojdbc.version>
</properties>
We also define here the installation directory of the JBoss AS. This way we can change it, if we want, using the command line option -D. Now we add a new profile, such that we have to explicitly switch the setup procedure on and that it is not part of the normal build:
<profile> <id>setupAs</id> <build> <plugins> ... </plugins </build> </profile>
If we have the current JBoss version as a maven artifact deployed in our maven repository, we can use the maven-dependency-plugin to download and unpack the JBoss to the installation directory given above:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.8</version>
<executions>
<execution>
<id>unpack-jboss</id>
<phase>package</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.jboss</groupId>
<artifactId>jboss-as</artifactId>
<version>${jboss.version}</version>
<type>zip</type>
<outputDirectory>${project.build.directory}/jboss</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
Now that the application server is unpacked, we have to add the JDBC driver as well as our application (or anything else you need). We set this up by adding another execution block to the maven dependency plugin:
<execution>
<id>copy</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>our-company</groupId>
<artifactId>our-application-ear</artifactId>
<version>${app.version}</version>
<type>ear</type>
<outputDirectory>${jboss.install.dir}/jboss-as-${jboss.version}/standalone/deployments</outputDirectory>
</artifactItem>
<artifactItem>
<groupId>com.oracle</groupId>
<artifactId>ojdbc6</artifactId>
<version>${ojdbc.version}</version>
<outputDirectory>${jboss.install.dir}/jboss-as-${jboss.version}/standalone/deployments</outputDirectory>
<destFileName>ojdbc6.jar</destFileName>
</artifactItem>
</artifactItems>
</configuration>
</execution>
Last but not least, we also want to adjust the standard configuration files to our needs. We can use the maven-resources-plugin to substitute variable values within each file. Therefore we add templates for these files to the resources folder of our JBoss module and call the goal copy-resources:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<executions>
<execution>
<id>copy-jboss-configuration</id>
<phase>package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${jboss.install.dir}/jboss-as-${jboss.version}/standalone/configuration</outputDirectory>
<resources>
<resource>
<directory>src/main/resources/jboss/standalone/configuration</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
<execution>
<id>copy-jboss-bin</id>
<phase>package</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${jboss.install.dir}/jboss-as-${jboss.version}/bin</outputDirectory>
<resources>
<resource>
<directory>src/main/resources/jboss/bin</directory>
<filtering>true</filtering>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
The values for the filtering can be given on the command line with the -D option. If the team has more than a few members, it is also possible to create for each user a properties file that contains his/her specific configuration values. If we use the OS user as filename, we can easily choose the file by the name of the currently logged in user. This way each team member can easily setup its own completely configured application server instance by simply running:
mvn clean install -PsetupAs
In order to prevent that the newly configured server is deleted with the next clean invocation, we disable the maven clean plugin for the normal build:
<plugin> <artifactId>maven-clean-plugin</artifactId> <version>2.5</version> <configuration> <skip>false</skip> </configuration> </plugin>
Within the setupAs profile created above, we have to enable it of course, such that we can delete the whole installation just by calling “mvn clean -PsetupAs”. Now switching to an older branch is easy as we don’t lose any time searching for the right configuration…
Developing your own maven plugin to verify the bytecode of your artifact
In this article the goal is to develop your own maven plugin that accesses at build time the artifact of your project and verifies the class files. I used this concept for my library jb5n to verify that for each MessageResource interface an appropriate key/value pair is available in the underlying resource bundle.
The first step is of course to create a new maven module or project using the mojo archetype:
mvn archetype:generate \ -DgroupId=sample.plugin \ -DartifactId=hello-maven-plugin \ -DarchetypeGroupId=org.apache.maven.archetypes \ -DarchetypeArtifactId=maven-archetype-plugin
This will create a ready-to-run maven project of type maven-plugin for you:
<groupId>sample.plugin</groupId> <artifactId>hello-maven-plugin</artifactId> <version>1.0-SNAPSHOT</version> <packaging>maven-plugin</packaging>
All necessary dependencies to develop your own maven plugin are already available. The archetype also creates a simple Mojo class:
/**
* @goal verify
* @phase verify
*/
public class MyMojo extends AbstractMojo {
/**
* @parameter default-value="${project}"
*/
private MavenProject mavenProject;
The maven goal as well as the default phase of the lifecycle the plugin runs in is given by the javadoc elements @goal and @phase. Newer versions of maven let you define these values with annotations. To access the outcome of the current build process we let our plugin run in the verify phase. We can access the file of our artifact by accessing the member variable mavenProject, which is injected by maven into our plugin with the above definition:
File artifactFile = mavenProject.getArtifact().getFile();
The File object from the above snippet will point to the jar file (in case we have chosen jar packaging for our artifact). Therefore we can open the jar file using Java’s SDK classes JarFile and JarEntry:
JarFile jarFile = new JarFile(artifactFile);
Enumeration<JarEntry> entries = jarFile.entries();
while(entries.hasMoreElements()) {
JarEntry jarEntry = entries.nextElement();
String jarEntryName = jarEntry.getName();
if(jarEntryName != null && jarEntryName.endsWith(".class")) {
getLog().debug(String.format("Processing jar file entry '%s'.", jarEntryName));
...
}
}
Now we can use a library like javassist or Java’s reflection API to analyze each class file within the artifact.
Martin's Developer World 