Publishing a Maven site having jacoco reports at Github's gh-pages.

When converting one of my pet projects from Cobertura to Jacoco I stumbled upon some small nuisance when publishing the site as a gh-page with the maven-scm-publish-plugin:

• Jacoco creates it's needed resources (images, javascript, css) in a directory called .resources, note the dot at the start.
• Now while the resources were successfully pushed to the gh-pages branch, they were missing afterwards in the published site firstly.
• I found the solution in a help article called Files that start with an underscore are missing.
• It seems, directories or files starting with a dot are not published as well.
• So the solution was quite simple: in the shell script I use for publishing the site I added a line which will touch a file called .nojekyll as suggested in the help article before invoking the maven-scm-publish-plugin and it worked :-)

Update: I had written an email to github before I just tried the .nojekyll solution and received an answer quite promptly, jekyll/site.rb has more explanations.

Update 2: instead of touching .nojekyll you may add src/site/resources/.nojekyll in your project as outlined in Adding Extra Resources of the maven-site-plugin documentation.

jenkins LTS 1.424.6 and java.lang.NoSuchMethodError: com.google.common.collect.ImmutableList.copyOf(Ljava/util/Collection;)Lcom/google/common/collect/ImmutableList;

While updating the parent version of JobConfigHistory+Plugin from Jenkins LTS version 1.424.2 to 1.424.6 I encountered
the following:

Using mvn dependency:tree, I saw that org.kohsuke.stapler:stapler:1.172 depends on
com.google.guava:guava:r06, this version does not include the symbol.
Version 1.424.6 of the WAR provides com.google.guava:guava:jar:11.0.1, which includes this symbol.
See Update to LTS 1.424.6 for the fix.

Using maven-release-plugin and maven-scm-plugin to tag all submodules of a multimodule project

I just created a sample multi module maven project in which by using the maven-release-plugin and the maven-scm-plugin I achieved my goal to create additional tags for the module artifacts as well. For a rationale see the included README.

There are two branches, one working with git and one with Subversion (in the master branch).

cobertura plugin and maven3 in a Hudson Installation

Now that Hudson 1.392 supports Maven3 I switched my first job to Maven3. One small caveat: you need a new, not released version of the Cobertura Plugin, more information is found in HUDSON-8362.

Triggering Hudson parameterized builds which include a file parameter using curl

My final goal is to run mvn release:prepare on my local machine to have greater control and trigger the actual mvn release:perform on Hudson, which will do the deployment in a controlled environment and archive the build log.

To achieve this, I want to upload the generated release.properties to the Hudson instance. This should be possible using the Parameterized Trigger Plugin. The tricky part is that the proposed solution on the plugin's Wikipage using buildWithParameters seems not to work, I always got HTTP/400 or HTTP/500 responses. After some tries and an analyze of the traffic with Charles I came up with two solutions, one using token authentication, the other one basic authentication. The important part seems to be to include the parameters json and Submit as well. Note that the file parameter is numbered, i.e. it is called file0.

Token authentication

curl -i -Fname=release.properties -Ffile0=@FILE_TO_UPLOAD \
-Fjson='{"parameter": {"name": "release.properties", "file": "file0"}}' \
-FSubmit=Build \
'http://HUDSON/hudson/job/JOBNAME/build?token=TOKEN'

The advantage of this is that no further user interaction is required, however you do not know who triggered the build.

Basic HTTP authentication

curl -i -uUSERNAME -Fname=release.properties -Ffile0=@FILE_TO_UPLOAD \
-Fjson='{"parameter": {"name": "release.properties", "file": "file0"}}' \
-FSubmit=Build  'http://HUDSON/hudson/job/JOBNAME/build'

The advantage of this is you know who triggered the build.

A simple way to get a git hash as version info into Android applications using Maven

I recently decided to do some Android programming. Enters Mittagstisch KA. I really like to know which sources applications are built from. Using Maven and it's Antrun-Plugin this is rather simple:

This will create a new string resource file, which is automatically picked up by Android's resource compiler and might be read in your application by an Activity like this:

final String gitHash = getResources().getString(R.string.info_githash);

Do not forget to add res/values/githash.xml to your .gitignore file otherwise you will be committing infinitely :-).