Continuing the series of articles, let’s check how we do integration tests for nexus plugins.
The kungfu virus scanner
The kungfu virus scanner is a simple nexus plugin. It will prevent nexus from caching infected files (it will still serve the file, but won’t cache it). To know if a file is infected or not, there is a “sophisticated” algorithm that checks if the file has the word “infected” in its name. It is used for demonstration purposes only and is useless for everything else. You can download its source files here.
To run our test, first of all, we will need a Nexus instance that will be launched and used to hold the plugin being tested. Originally we used the maven-dependency-plugin to unpack the Nexus bundle. Then, we used the same to copy the plugin under test to nexus plugin-repository directory. This alone would mean about 20 lines in the POM and no potential for reuse between different plugins, so we decided to write a specific testing plugin to create the environment required by Nexus plugins. Thus was born the nexus-test-environment-maven-plugin (we should come up with a shorter name =D ).
Flex compiler does use lot’s of memory and CPU resources, so does Flexmojos. There’s not much new in here.
Some time ago I was reading this blog post with some memory parameter suggestion. And guess what, compilation becomes faster using it.
There are 2 ways to change maven JVM settings:
1 – Editing launch files
Edit mvn (non-Windows) or mvn.bat (windows) and add the following line:
$ set MAVEN_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=256m -XX:PermSize=64m
On Windows you can add that on the first line and on non-Windows systems you must add that after “#!/bin/sh”
2 – Setting an environment variable
This process will vary from OS to OS.
Just add an environment variable with name equal to “MAVEN_OPTS” and the value equal to “-Xms512m -Xmx1024m -XX:MaxPermSize=256m -XX:PermSize=64m” both w/o quotes.
The main advantage for the second method is that it will still work even after Maven is updated.
In the third part of this series I will talk about how integration tests (and unit tests) are done on Flexmojos. If you haven’t been following along, you should read the first and second posts of this series.
The buzz word this week in the Flex universe was FlexPMD. That is a really good tool that many missed when working with Flex.
A curious person that I am, I downloaded the sources, just to sneak a peek, see some code, basically watch and learn. What a pleasant surprise it was to discover that it is built with Maven, eliminating the need for the usual cygwin/ant combination. But I was even more surprised! Flexmojos is used to build the flex side of FlexPMD.
That is so cool. Using FlexMojos is quickly becoming a best-practice.
A few days ago we changed nexus integration tests to use an embedded version of nexus instead of using a forked VM. Before every test Nexus is started and then stopped again after the test completes. This is done once for each test class (Junit: @BeforeClass=start nexus, @AfterClass=stop nexus).
During the first run we noticed some problems.Each time Nexus started, VM would use an additional 45Mb of memory. Soon we realized that our embedder was not working right. Stopping Nexus was not removing it from memory.
Setting all fields to null after stopping helped somewhat. But now instead of 45Mb of leak we were getting 40Mb, which was still too much when we had more then 200 tests to run. It was time to profile our tests.
At Sonatype we use yourkit for profiling, so I will demonstrate how to use yourkit to profile tests executed by maven. You should be able to use the same principle with any other profile tool.