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.

Strange problems with git-svn fatal: "Cannot open '.git/wJj4wQYBct': Permission denied hash-object -w --stdin-paths --no-filters: command returned error: 128"

While trying to convert an internal Subversion repository with git-svn I ran into the same error over and over again. After a lot of successful revision conversions, I always got:

fatal: "Cannot open '.git/wJj4wQYBct': Permission denied
hash-object -w --stdin-paths --no-filters: command returned error: 128"

After searching the web (the usual suspects http://stackoverflow.com/ and Google) and trying a lot of the given hints, I finally tried to checkout the trunk of the repository with subversion directly and did not succeed as well.
Now I firstly was even thinking our subversion repository might be corrupt until a sudden insight grew in me: while I really like the Macbook Pro given to me by the company, the Avira virus scanner was detecting the EICAR test virus in the test suite, this showed up in the quarantine logs!
Now the rest was a piece of cake: by applying the hints on the Avira KB for excluding specific paths I finally succeeded by excluding only this specific directory where the conversion took place.

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.

Restarter script for Jenkins

• I am fighting with my Jenkins instance being down every other day.
• Getting bored of sshing to the host and restart the instance, I wrote a small restarter script.

javax.net.ssl.SSLPeerUnverifiedException after installation of a new JDK on MacOSX

• After installing the new JDK (1.6.0_26) as normal user having the authentication dialog pop up for my admin account. I had loads of problems with javax.net.ssl.SSLPeerUnverifiedException popping up.
• I even was not able to start the /Applications/Utilities/Java\ Preferences.app/ and got a strange error.
• Logging in as admin did not help either, I still was not able to start the preference app.
• I downloaded the JDK as admin again and repeated the installation.
• I rebooted my system and now was able to open the preference app, reset to default options and the javax.net.ssl.SSLPeerUnverifiedException were gone.

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.