Olivier Lamy runner and open source hacker

Update 11 Sep 2013: All plexus-compiler released!
Because you usually write code very fast, you can sometimes made mistakes.
To prevent some stupid errors, folks from Google write the error prone compiler.
Have a look at the various detected patterns (yeah definitely more interesting than checkstyle :P )
Kudos to Alex Eagle for the contribution!.
The configuration to use it:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.1</version>
  <configuration>
    <compilerId>javac-with-errorprone</compilerId>
    <forceJavacCompilerUse>true</forceJavacCompilerUse>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>org.codehaus.plexus</groupId>
      <artifactId>plexus-compiler-javac-errorprone</artifactId>
      <version>2.3</version>
    </dependency>
    <!-- NOTE this one will not be needed when plexus-compiler-javac-errorprone and error-prone will be released -->
    <dependency>
      <groupId>org.codehaus.plexus</groupId>
      <artifactId>plexus-compiler-javac</artifactId>
      <version>2.3</version>
    </dependency>
  </dependencies>
</plugin>

Feel free to test, I hope we will be able to have released versions of those artifacts soon.

NOTE: Not usual but this blog entry is not technical, you won't see any xml or java code :-)

That's how my 9 yo daughter see our new future life :-)



NOTE: I tried to explain to her it's not possible to have kangaroo as pet. So she answered to me: "Ok I prefer a koala" :-)

So we wanted to move to an english speaking country.
We merged our specs:

• wife specs: country with good cupcakes and some beaches.
• my specs: sunny country and good beer/wine

The short list was:

• US: but no due to too much guns
• UK: too much rain (and I'm French and you know the history :-) )
• Canada: too cold !
• Australie: cupcakes, beers, beaches and sun etc...

In fact the choice was pretty easy :-).
So we will relocate around mi march to Melbourne, Australia (Yes The most livable city in the world see http://en.wikipedia.org/wiki/World's_most_livable_cities).

While my wife will go to the beach, I will work for a small/medium company (I don't know yet what is small/medium/huge in this country): http://ecetera.com.au. (see smart people http://youtu.be/HGSg2kfW2sA).
The good news is 50% of my $DAYJOB will be continuing hacking on open source ! and the other 50% will be consulting/training on this open source.

<marketing>
If you need some consulting on open source in the Australia area contact me :-)
</marketing>

I'd like to thanks @Talend for the crazy 1,5 year dedicated to Apache hacking !
It was a really great pleasure to work with so amazing team !!
(@glenmazza this relocation will help me to reduce my english typos :P )

<personnal marketing in French>
Je vends ma maison située ici
Pas encore eu le temps de faire annonce dans un circuit de vente officielle.
L'annonce sera:
Maison individuelle de 140m2 sur un terrain de 650 m2 avec 5 chambres, 1 bureau, sous sol total. Située dans secteur calme, proche écoles, à 5 min du RER C.
Rez de chaussée: 1 chambre, 1 bureau, salle à manger, cuisine, salle de bains (refaite en 2006) et WC.
Etage (construit en 2008): 4 chambres, salle de bains et WC.
Libre Juillet 2013.
Si vous êtes intéressé envoyez moi un email: olamy AT apache DOT org
</personnal marketing in French>

NOTE: I'm looking for a small apartment only for myself @Melbourne for mid march until august. Contact me if you have some proposals.

Next blog entry will be probably from the other side of the world :-)

Maybe you don't know because that's not very well documented :-) but Maven site support Markdown format ! It's just a matter of configuring the site plugin !

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-site-plugin</artifactId>
        <version>3.2</version>
        <dependencies>
          <dependency>
            <groupId>org.apache.maven.doxia</groupId>
            <artifactId>doxia-module-markdown</artifactId>
            <version>1.3</version>
          </dependency>
        </dependencies>
      </plugin>

Now add your markdown files with .md extension in src/site/markdown

And that's it ! You are now "à la mode" and you use markdown :-)

I agree that must be per default and no need of extra xml to write

See the documentation of under incubation Helix project, we use Markdown (http://helix.incubator.apache.org)

Have Fun

Recently Kohsuke (@kohsukekawa) wrote a plugin to let you apply a patch on Jenkins job for testing purpose.
See Blog entry.

That's a pretty good idea as most of the time, you can have very long build. Integrations tests with selenium running on various os/browsers (some you don't have or don't want to install) or tests on various databases.

So usually hack, commit/push the change and cross fingers for not break the build on your Jenkins instance (don't tell me you never did that :-) ).

While ago I started a Maven plugin to be able to interact with github/jira (see blog entry).

So I have enhanced this plugin a bit to generate a diff/patch (I have tested on both svn/git) and post it to Jenkins to run the job with applying the patch on the job workspace.

NOTE: you need to install the Jenkins plugin first Patch Parameter Plugin.

Then run the following Maven cli:

mvn patch-tracker:post -Dpatch.serverUrl=http://localhost:8080/job/maven-dependency-update-trigger-plugin -Dpatch.patchTrackerSystem=jenkins
Maven will ask you user/password etc..

Now that's cool you can keep your local cpu/memory to listen musics, watch videos, play games etc... while your patch is tested on a remote Jenkins instance.

NOTE: The maven plugin is still in sandbox without any release. So you need to install it manually (sources are here: https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-patch-tracker-plugin) or consume it from this snapshot repository: https://repository.apache.org/content/repositories/snapshots

BTW you can use curl too :-) curl --user uid:password -X POST -F "patch.diff=@patch.txt" https://jenkinshost/job/X/buildWithParameters?delay=0sec
Don't miss to add a build parameter patch file.
If you use svn, configure checkout-strategy to "Emulate clean checkout by first ...."

All feedbacks are welcome!

So Have Fun !

The Apache Maven team just released a first version of a new plugin to be able to publish Maven websites to a scm. (Maven SCM Publish Plugin)
The first goal was to be able to commit web sites to the svnpubsub Apache infra for websites.

Remember the migration to svnpubsub is mandatory for the end of the year.

Yes you remember as (if you are an Apache committer) how long it can take to have a *.apache.org website live updated :-).

You usually scp to people.a.o and wait the end of rsync (long coffee break possible!) But now (thanks to Apache infra !), just commit your website to svn and the site is up2date within minutes !!

Note: as we have a Maven Scm Api we can support most of the supported scm by the Maven scm (honestly I have tested only svn and git :-)).
So it works too for git (github gh-pages included see documentation git branch section)

The trick is you must use different configuration and command line if you publish a mono module or multi modules build. See samples and documentation here:

• mono module
• multi modules

Nice feature is the cleanup(delete) of not anymore generated files. They are now deleted from the scm. The plugin simply compare your generated website and the content from scm and take care of removing not anymore produced files.

Have a look at the other tips in this page.
The most important is to use the tryUpdate mode (not the default).

<tryUpdate>true</tryUpdate>

So have fun writing documentation on Apache projects and publish it to live very fast :P

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

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.