Recently my co-worker James suggested we automate our tests on our project using JMeter and gave me his webpage about the trials and tribulations he went through to get it set up.  It linked to a wiki page, in which someone had created a JMeter plugin for Maven.

Well awesome, it shouldn’t be too hard to set up.  And it wasn’t, I had the JMeter tests up and running in a short amount of time.  But one of the problems was that I wanted to set it up in a more generic way so that we could define different parameters on each of the CI environments we ran. 

For this task, I first tried using filtering in maven, which I got working.  But what you end up with is a JMX file that is basically unusable by default in JMeter. If you ever wanted to run it again standalone in JMeter, you’d have to modify the variables in the JMX file to work correctly. Vice versa, if you set up your test using JMeter, you have to remember to modify it so that the maven variables you need are in the places you need them.

JMeter already has a system in it where you can define variables in the JMX files (and give them defaults, fancy la la!).  For example, say you want to define a variable for a host name.  Inside your JMeter JMX file, you can do something like this:

<stringProp name="HTTPSampler.domain">${__P(someVariableName, localhost)}</stringProp>

Now, you have defined someVariableName to be a variable within your JMX file.  The second value, in this case localhost, is the default if no variable override has been given.

The way to override these variables is with the -J option on the command, in this form:

-JsomeVariableName=yourhost.com

and all the variables called someVariableName will have the value yourhost.com.

Now, with the minor modifications I have made to the JMeter Maven plugin, you can now define the values for these variables inside of your pom.xml, like so:

<jmeterUserProperties>
      <someVariableName>yourhost.com</someVariableName>
</jmeterUserProperties>

and it is just the same as using -J on the JMeter command line.

The way we’re actually going to use it is to combine it with maven variables, like so:

<jmeterUserProperties>
      <someVariableName>${ourhostname}</someVariableName>
</jmeterUserProperties>

So now, we can just do:

mvn -Dourhostname=ourspecialhost ...

and be able to run site specific JMeter tests with only changing the arguments on the command-line.

I will be putting together a page in the next day or so with all the libraries needed to set this up, similar to the wiki page.

The problem was the latest version of the Maven war plugin (2.1-alpha-2-SNAPSHOT) changes the way that skinny WARs are created for packaging in EARs. The documentation hasn’t quite made it to the website yet.  Instead of using <warSourceExludes> to exclude the JARs that you do not want, you have to now use <packagingExcludes>.  It’s described in this bug here.

We had it working great and then something ridiculous happened that caused WARs with their complete libraries (as opposed to stripped-down ones) to be included in the EAR, for no apparent reason. This caused a number of headaches and issues with the application, that we didn’t know until it was deployed, because we failed to recognize that the EAR had nearly doubled in size.

You may be wondering, “Hey, I just read two of your dumb paragraphs and I haven’t seen the word ‘groovy’, ‘maven’, ‘magic’, or ‘using’ yet.” Well, wouldn’t it have been nice if we knew instantly that the EAR had grown, when trying to build? That’s where the using the groovy maven magic plugin can help!

My co-worker James and I attempted to use the maven enforcer plugin, but it would have taken too much work and we would have needed to write a custom plugin for it to check the size of the EAR. So we decided to do it with Groovy. Here’s the code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<plugin>
  <groupid>org.codehaus.mojo.groovy</groupid>
  <artifactid>groovy-maven-plugin</artifactid>
  <version>1.0-beta-4-SNAPSHOT</version>
  <executions>
    <execution>
<phase>verify</phase>
      <goals>
        <goal>execute</goal>
      </goals>
      <configuration>
        <source>
 
          def ear = new File("$pom.basedir/target/${project.artifactId}-${project.version}.${project.packaging}")
          log.info("${ear?.length()}");
          def maxsize = project.properties['ear.maxsize'];
          if (ear?.length() > maxsize?.toInteger()) {
            fail("EAR Exceeds maximum size allowed.");
          }
        </source>
      </configuration>
    </execution>
  </executions>
</plugin>

This beginning part essentially defines the groovy plugin, and states run the code during the maven’s “verify” phase, so we know that the EAR is already created:

1
2
3
4
5
6
7
8
9
10
11

<plugin>
  <groupid>org.codehaus.mojo.groovy</groupid>
  <artifactid>groovy-maven-plugin</artifactid>
  <version>1.0-beta-4-SNAPSHOT</version>
  <executions>
    <execution>
<phase>verify</phase>
      <goals>
        <goal>execute</goal>
      </goals>
</execution></executions></plugin>

The groovy code is really straight forward. First we get a reference to the file:

13
14

def ear = new File("$pom.basedir/target/${project.artifactId}-${project.version}.${project.packaging}");
log.info("${ear?.length()}");

We’re using variables defined directly in the POM, so we know the name of the file. We also print the length of the file out, for sanity’s sake.

Next we get the max size value:

15

def maxsize = project.properties['ear.maxsize'];

This is defined later in the pom.xml file, under properties:

<properties>
        <ear.maxsize>60000000</ear.maxsize>
</properties>

As you can see, it is set to near 60MBs.

Finally, and obviously, we check the two values against each other, and fail the build if the EAR is bigger than the size allowed.

16
17
18

if (ear?.length() > maxsize?.toInteger()) {
  fail("EAR Exceeds maximum size allowed.");
}

The fail() call in groovy allows you to fail the build with a message attached to it.

So now, if anything fishy happens with the EAR, we’ll be able to know as soon as our CI environment attempts to build it. This is a really simple example, but you could see how integrating groovy into maven could allow for some very powerful things to be done.