Monday 27 August 2012

Maven Assembly/Dependency plugins useJvmChmod field WTF ?

It looks not a lot folks knows a strange named option  from the Assembly and Dependency Maven plugins.
The name is useJvmChmod. Sure when reading this name you can say: "WTF ?????".
Both plugins use a component called plexus-archiver (which pack,unpack files and can set files permissions).
By default on unix platform, this component will fork a process to do chmod command line call and for each files (ouch !!!! for large distributions or unpack goal).
So long ago now (yup 2 years is long in our world :-)), I added a configurable mode to use file permission methods from jdk1.6 and not using anymore forked command line call to chmod.
This is why it's called useJvmChmod (sorry I'm sometimes not really good on naming marketing :-)).
By the way, if your build is still 1.5 that will works as it's done trough reflection (see initial commit ).
Note this option is available since assembly plugin 2.2 and it's now available in the fresh release of dependency plugin 2.5.1 (thanks to @atlassian folks for the issue report: https://jira.codehaus.org/browse/MDEP-368).
So if you assembly plugin or use unpack goal from the dependency don't miss this attribute to true!
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-assembly-plugin</artifactId>
          or
          <artifactId>maven-dependency-plugin</artifactId>
          <configuration>
            <useJvmChmod>true</useJvmChmod>
          </configuration>
        </plugin>
NOTE: if you use useJvmChmod special permissions at group level won't be apply as it doesn't exists in java

Thursday 2 August 2012

Maven Surefire configuration for CI server

I used this configuration for long time now but not sure you know that.
The use case is an application creating a temp file to store values (File.createTempFile( "wine.txt", "wine" ); )
Running it locally no problem.
But now you have a ci server running the same Maven project with various parameters:
* one fast only executing unit tests
* one longer running selenium integration tests.

On Unix server, the temp directory is shared for all users (usually /tmp, /var/tmp etc...).
So if your build runs in parallel they will share the same file (can go to weird results ..)

To avoid such case, you can configure surefire plugin as it


      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <systemPropertyVariables>
            <java.io.tmpdir>${project.build.directory}</java.io.tmpdir>
          </systemPropertyVariables>
        </configuration>
      </plugin>

As it each build will use a separate tmp directory and temporary files won't be shared anymore.