Jenkins: Pimp It Up!

Some days ago, I started to review what plugins are available for Jenkins, my favorite CI server. I haven't done so for a long time, so I was somewhat surprised to see a full universe of plugins (380+) listed in the Wiki...

There is next to everything you can imagine. Among the plugins I would like to suggest for consideration are these:

• Dependency Graph View Plugin – Shows the dependency graph of the Jenkins projects using graphviz. This greatly helps to keep track of dependencies between all your Jobs.
  
  



• Disk Usage Plugin – This plugin calculates and records disk usage (space for builds and workspace) per project and per build, and can display trend graphs.
  
  



• Global Build Stats Plugin – can be used to gather and display global build result statistics, monitoring over time, and show nice graphics.
  
  



• And, of course, all the static analyzing plugins that scan result files of several static code analysis tools and visualize the results as trend graphs:
  • Checkstyle Plug-in
  • Cobertura Plugin
  • FindBugs Plugin
  • JavaNCSS Plugin
  • PMD Plugin
  • Task Scanner Plugin
  • Warnings Plugin
  
  
  

Have fun!

Read More

Maven Plugins: Upgrade with Care!

Upgrading Maven Plugins: Tips and Issues

After having shown the list of current Maven plugin versions in my previous post, now I'm going to share my experiences with upgrading. Just like expected, some of the new plugins did not work out of the box or required some changes in configuration:

maven-checkstyle-plugin

We have used version 2.3 previously which is based on Checkstyle 4.4. In contrast, plugin version 2.4 is eventually built on top of Checkstyle 5 which better supports Java 5 language features (I wrote a post on that issue). The configuration is not fully compatible, so you would have to upgrade it.

maven-javadoc-plugin

Starting with version 2.6, JavaDoc plugin can detect the Java API link for the current build. This did not work for us (probably due to missing proxy configuration), so we had to switch it off by setting detectJavaApiLink property to false. See plugin site.

taglist-maven-plugin

The configuration of tags has changed and is now a bit more extensive. Old format (using tags element) is still supported, but deprecated. See plugin documentation.

findbugs-maven-plugin

I have used version 2.2 which was the most recent one when changing the POM. However, this yielded some strange errors during site generation. This is the strack trace:

Generating "FindBugs Report" report.
  Plugin Artifacts to be added ->...
  AuxClasspath is ->D:\Profiles\Default User\.m2\repository\org\apache\maven\reporting\maven-reporting-impl\2.0\maven-reporting-impl-2.0.jar;...
[java] Exception in thread "main" java.io.FileNotFoundException: D:\builds\...\User\.m2\repository\...\maven-reporting-impl-2.0.jar;D:\Profiles\Default (The filename, directory name, or volume label syntax is incorrect)
[java]  at java.util.zip.ZipFile.open(Native Method)
[java]  at java.util.zip.ZipFile.<init>(ZipFile.java:114)
[java]  at java.util.zip.ZipFile.<init>(ZipFile.java:131)
[java]  at edu.umd.cs.findbugs.classfile.impl.ZipFileCodeBase.<init>(ZipFileCodeBase.java:53)
[java]  at edu.umd.cs.findbugs.classfile.impl.ZipCodeBaseFactory.countUsingZipFile(ZipCodeBaseFactory.java:92)
[java]  at edu.umd.cs.findbugs.classfile.impl.ZipCodeBaseFactory.makeZipCodeBase(ZipCodeBaseFactory.java:46)
[java]  at edu.umd.cs.findbugs.classfile.impl.ClassFactory.createFilesystemCodeBase(ClassFactory.java:97)
[java]  at edu.umd.cs.findbugs.classfile.impl.FilesystemCodeBaseLocator.openCodeBase(FilesystemCodeBaseLocator.java:75)
[java]  at edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.processWorkList(ClassPathBuilder.java:564)
[java]  at edu.umd.cs.findbugs.classfile.impl.ClassPathBuilder.build(ClassPathBuilder.java:195)
[java]  at edu.umd.cs.findbugs.FindBugs2.buildClassPath(FindBugs2.java:584)
[java]  at edu.umd.cs.findbugs.FindBugs2.execute(FindBugs2.java:181)
[java]  at edu.umd.cs.findbugs.FindBugs.runMain(FindBugs.java:348)
[java]  at edu.umd.cs.findbugs.FindBugs2.main(FindBugs2.java:1057)
[java] Java Result: 1

As you can see, we are using Windows default for local Maven repository (D:\Profiles\Default User\.m2) which obviously is causing a problem with the path later on. How sick is that?!?

Then, after having tried this and that, I discovered there is a brand new version 2.3 available so I tested that one and guess what – everything works fine again! Hence, don't use version 2.2, it seems to be broken...

docbkx-maven-plugin

The latest version of that plugin is 2.0.9, but that did not work correctly. It failed the build with this error:

ValidationException: null:30:723: Error(30/723): fo:table-body is missing child elements.
Required Content Model: marker* (table-row+|table-cell+)

The given line/position information did not match to anything suspicious, and I could not see anything wrong in our XSL files. So, no idea what this issue is telling me or what could I do about it. That's why I rolled back to 2.0.8 which just works fine.

The Bottom Line

With the given plugin versions, we are up to date again and managed to get rid of some issues hitting us since quite some time. Additionally, we are well prepared for upgrading to Maven 3. I hope I will be able to do so soon, to check if this is really a "drop-in replacement"... I will let you know!

Read More

Maven Plugins: Current Versions

Upgrading Maven Plugins

In preparation for a later switch to Maven 3 (which is already knocking on the door) as well as to get rid of some plugin related issues we are suffering from, I decided to update the Maven plugins we use for build and site generation.

Of course, we are following best practice and are locking down the version of all plugins in project.build.pluginManagment.plugins section. This is done in the company's topmost POM, so that all company projects would use the same versions once they reference the latest parent POM.

As you might know, upgrading to new plugin versions is always an adventure and you have to test your builds seriously, which is of course hard when you are going to change the company settings...

Build Plugins

Well, here is the list of build plugins we now use with their current version, as well as (in brackets) the version that Maven 3.0-alpha5 defines in its internal POM. I have highlighted where both versions differ:

• maven-archetype-plugin: 2.0-alpha-5 (see comment below)
• maven-assembly-plugin: 2.2-beta-4 (2.2-beta-4)
• maven-clean-plugin: 2.3 (2.3)
• maven-compiler-plugin: 2.0.2 (2.0.2)
• maven-dependency-plugin: 2.1 (2.0)
• maven-deploy-plugin: 2.4 (2.4)
• maven-ear-plugin: 2.4 (2.3.1)
• maven-ejb-plugin: 2.2 (2.1)
• maven-enforcer-plugin: 1.0-beta-1
• maven-help-plugin: 2.1 (2.1)
• maven-install-plugin: 2.3 (2.3)
• maven-javadoc-plugin: 2.6.1 (2.5)
• maven-jar-plugin: 2.3 (2.2)
• maven-release-plugin: 2.0-beta-9 (2.0-beta-9)
• maven-resources-plugin: 2.4.1 (2.4.1)
• maven-site-plugin: 2.0.1 (2.0.1)
• maven-source-plugin: 2.1.1 (2.0.4)
• maven-surefire-plugin: 2.4.3 (2.4.3)
• maven-war-plugin: 2.1-beta-1 (2.1-alpha-1)
• build-helper-maven-plugin: 1.4
• failsafe-maven-plugin: 2.4.3-alpha-1
• cargo-maven2-plugin: 1.0
• docbkx-maven-plugin: 2.0.8

It's a bit strange that Maven 3.0-alpha5 (which came out end of November) does not use the latest version of all those plugins, most of them having been released before that date. I don't know if this was intentional or not... Let's hope it's not because of unsure quality of latest plugin versions ;-) Anyways, I decided to upgrade to the latest available version for all plugins.

Reporting Plugins

Here's the list for plugins related to site reports:

• cobertura-maven-plugin: 2.3
• findbugs-maven-plugin: 2.3
• jdepend-maven-plugin: 2.0-beta-2
• maven-checkstyle-plugin: 2.4
• maven-jxr-plugin: 2.1
• maven-pmd-plugin: 2.4
• maven-project-info-reports-plugin: 2.1.2
• maven-surefire-report-plugin: 2.4.3
• taglist-maven-plugin: 2.4

I'm going to show some tips and issues when upgrading to these versions in an upcoming post...

Read More

Update to Checkstyle 5.0

Checkstyle 5 is available!

This is good news: a new version of Checkstyle is available that better supports Java 5 language features (like generics, annotations or package-info files). Additionally, some checks are cleaned up a bit, for instance concerning their parent in which they are contained. See the release notes for details.

Due to these changes, Checkstyle 5.0 is not fully compatible to previous versions 4.x – which is already indicated by the version number leap. Hence, don't expect the upgrade to be smoothly!

Nevertheless, I thought it would be time to upgrade, so here is what I did...

Step 1: Upgrade checkfile configuration

Due to the incompatabilities, I had to apply some changes to our checkstyle configuration to make it work with Checkstyle 5. To be sure I did it right, I have downloaded and used the Checkstyle binaries and checked my configuration for just a simple project. Hence, before upgrading Eclipse and Maven Checkstyle integration, I know my configuration is correct.

BTW, we are using a common checkstyle configuration file for all projects, and reference this "global" file with Maven and Eclipse in different ways:

• With Maven, we use a custom artifact that contains nothing but our checkstyle.xml file. This in turn is included as build extension in our main base POM. See this post for more details.


• For Eclipse, we use the "Eclipse Checkstyle Plugin" that provides a Remote Configuration option to reference the configuration file on an internal file server.

Step 2: Upgrade Eclipse Plugin

There is a new Beta-Release of Eclipse Checkstyle plugin (eclipse-cs) available on its update site http://eclipse-cs.sf.net/update. At the time of writing, there are three features available:

• Eclipse Checkstyle Plug-in – version 5.0.0-beta4
• Eclipse Checkstyle Plug-in 4.4.x -> 5.0.0 Migration (Optional) – version 5.0.0-beta4
• m2eclipse Maven Synchronization Plugin (Optional/Experimental) – version 0.0.3

Oh, seems there would have been some help in migrating from Checkstyle 4.4 to 5.0... Doesn't matter, I always like to see what the changes are so it's good to do it manually.

The m2eclipse Synchronization plugin is a new feature providing mechanism to synchronize Checkstyle rules and configuration between the maven plugin and eclipse-cs. Sounds really interesting... but let's do one step after the other and test this later.

So. I just installed the "Eclipse Checkstyle Plug-in" feature. Eclipse didn't recognize that this actually is an update, so you have to uninstall the previous eclipse-cs installation manually.

Why that? Well, the "package" has changed from com.atlassw.tools.* to net.sf.eclipsecs.*, and this applies to the feature's ID, too. Moreover, this renaming also affects the buildCommand and nature in .project files, they have to be net.sf.eclipsecs.core.CheckstyleBuilder and
net.sf.eclipsecs.core.CheckstyleNature now.

Additionally, the notation for file sets has been changed: a file set previously configured as src\\main\\java\\com\\mycompany\\.* does no more match to any file; instead, it has to be the slash now like in src/main/java/com/mycompany/.*.

Okay, maybe I should have tried the Migration plugin... Anyways, after these changes everything works fine for me in Eclipse.

Step 3: Upgrade Maven Plugin

Good. Last piece is Maven, which provides the Maven 2 Checkstyle Plugin. However, the current version is 2.2 which is based on Checkstyle 4.4 by defining these dependencies:

<dependency>
  <groupId>checkstyle</groupId>
  <artifactId>checkstyle</artifactId>
  <version>4.4</version>
</dependency>
<dependency>
  <groupId>checkstyle</groupId>
  <artifactId>checkstyle-optional</artifactId>
  <version>4.4</version>
</dependency>

There is an interesting way to override the plugin's dependencies pointed out by Brian Fox, but that's not going to work for us because Checkstyle versions 4.4 and 5.0 are not API compatible.

What can we do? Not much... we'll have to wait for a new version of the Checkstyle plugin that updates to Checkstyle 5. There is this Jira issue, and patches have already been provided some time ago. It's only that there seems to be no progress whatsoever... Checkstyle 5.0 is officially out since April 18th, so there is no reason to wait any longer! Create a new release (for my part, alpha/beta is fine as well) – please!!!

If you really need the plugin to be fixed now, you could checkout the plugin's sources and built your own version, applying the patch provided in the Jira issue. That works, but is nothing we want to do regularly!

Read More

Maven Enforcer Plugin: cool and annoying

As a Maven expert, you probably have heard of maven-enforcer-plugin, "The Loving Iron Fist of Maven", as they say.

It's so cool!

The idea is pretty cool: the plugin provides goals to ensure that the environment used to run Maven is like you – the POM author – expected it to be. There are checks for constraints on the version of Maven or JDK, on the OS family, to enforce certain dependency requirements, and much more. This list on the web site gives you an impression on what kind of checks are provided.

Do you know what happens when you write your POMs and settings for Maven version 2.0.9 or greater, but somebody is still using an outdated 2.0.4? Well, this kind of issues is annoying and you better make sure it does not happen.

The current version of maven-enforcer-plugin (at the time we set it up) was 1.0-alpha-4 which sounded not very mature, but nevertheless we decided to use it. For our projects, we identified a couple of things we wanted to check, and we configured the plugin accordingly:

• Java Version: should be 1.5.
• Maven version: must at least be 2.1.0.
• Enforce defined versions for all plugins, and disallow any use of "LATEST", "RELEASE" or "SNAPSHOT" as a version for any plugin.

Hey, SNAPSHOT plugins are just dangerous and you should never, never ever depend on them. The only exclusion could be plugins developed inhouse, but actually, no – not really. Bah, don't use SNAPSHOT plugins. Period.

So, we tried to setup our enforcer plugin configuration like this:

<plugin>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>1.0-alpha-4</version>
  <executions>
    <execution>
      <id>enforce-versions</id>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <requireMavenVersion>
            <version>[2.1.0,)</version>
          </requireMavenVersion>
          <requireJavaVersion>
            <version>1.5</version>
          </requireJavaVersion>
          <requirePluginVersions>
            <message>Best Practice is to always define plugin versions!</message>
            <banLatest>true</banLatest>
            <banRelease>true</banRelease>
            <banSnapshots>true</banSnapshots>
          </requirePluginVersions>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

Of course, we wanted to apply the same checks on command line as within Eclipse when using m2eclipse plugin.

It's so annoying!

Well, and here is where the trouble started...

Shot one. Oh, wait, we are using Maven version 2.1.0-M1 currently. Guess what? This is not included in range [2.1.0,) which means every version x >= 2.1.0. Okay. Let's use [2.1.0-M1,) instead.

Shot two. What about Eclipse? The check fails within Eclipse, and it turns out that the version number reported by the Maven embedder used by m2eclipse (0.96 at that time) is 2.1-SNAPSHOT. Thus, enforcer fails and we'll have to use this for the Maven version specification:

<version>[2.1.0-M1,),[2.1-SNAPSHOT,)</version>

Ugly, but still manageable...

Shot three. My team reported the enforcer plugin to sometimes use some "thinking time" when checking the environment – it seems to hang for couple of seconds. We all see that betimes, and I have no idea what it is caused by. Actually, performing those version checks should be fast as light, right?

What makes this even worse is the fact that in multi-module builds, enforcer plugin is called for each subproject. It binds by default to the validate lifecycle phase which is executed for every subproject. However, the environment does not change very much during a single build, so it would be sufficient to check that only once per Maven call...

Shot four. When establishing the cool Sonar quality management platform, Maven started to complain that "some plugins are missing valid versions". Seems that Sonar defines dependencies to other artifacts used internally, but doesn't give a version for them. All you can do is specify a version for those plugins in the <pluginManagement> section of one of your parent POMs. That's actually not what you want: explicitely list versions for artifacts used internally by the current version of a build tool... But what else can you do? Completely disable the requirePluginVersions check?

Shot five. After upgrading m2eclipse to version 0.97, it does not correctly handle our enforcer configuration any more and instead yields an error:

org.apache.maven.lifecycle.LifecycleExecutionException: Invalid or missing parameters: [Mojo parameter [name: 'rules'; alias: 'null']] for mojo: org.apache.maven.plugins:maven-enforcer-plugin:1.0-alpha-4:enforce

This is a known issue, and you have to uncheck the "Skip Maven compiler plugin when processing resources" checkbox in the project's properties. That means, we have to change configuration for all our projects :-(

Moreover, it was the default to check this option and it seems to have negative performance impact when deselected.

Game over. This is the point where we eliminated enforcer plugin. Too much pain for a little helper tool. One of those things that seems to be quite cool at first glance, but starts to annoy you very soon.

Read More

Spring Web Flow: watch out!

Starting in November 2008, we found a concurrency issue in our web applications that are based on the following framework stack:

• Spring 2.5.4
• Spring Web Flow 2.0.5
• JSF 1.2_09
• Facelets 1.1.14a
• Trinidad 1.2.9

The issue

For a single user, everything run fine. However, when multiple users hit the application, we got some strange exceptions occasionally – not always and not always at the same place. However, we managed to get this one regularly with our JMeter tests:

SCHWERWIEGEND: Error Rendering View[/plan/FindPlan.xhtml]
javax.el.PropertyNotFoundException: /file:/.../facelets/ipl-comboBox.xhtml @64,30 value="#{localField.jsfValue}": Target Unreachable, identifier 'localField' resolved to null
at com.sun.facelets.el.TagValueExpression.getType(Tag ValueExpression.java:62)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ValueRenderer.getDefaultConverter(ValueRend erer.java:78)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.renderNonElementCon tent(SimpleSelectOneRenderer.java:323)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAllAsNonElement(F ormElementRenderer.java:172)
at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.encodeAll(FormElementRe nderer.java:105)
at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:335)
....

This exception got rendered on the page instead of the actual component. At other times, we got java.lang.IllegalStateException and other funny behavior.

The strange thing is, the referenced variable is put into the flow scope, of course. Now that we took the time to debug into this issue, we can see that the scopes seem to be correctly filled and the property is actually there, it's just that the ELResolvers could not retrieve it...

Actually, we thought it would be caused by our Java or Spring configuration code, presumably using wrong bean scope or the like.

...is fixed!

Guess what... now I have been pointed to this bug of Spring Web Flow version 2.0.5: Class SimpleELContext is not thread-safe, but is stored in some application singletons :-( See this or this thread for more details.

The good news is, the bug is fixed in version 2.0.6; we have upgraded our projects and load tested them, and everything is just fine.

But...

IMO this is leaving a stale aftertaste. I'll tell you why.

That issue is a severe one: web applications using SWF 2.0.5 are just not working for concurrent users. Everybody using SWF in this version (maybe earlier versions as well) is affected. Given that, it seems strange that

• the issue hasn't been reported and fixed earlier: Version 2.0.5 has been published on 14th of November, and it took more than 2 weeks for the Jira issue to show up.
• this issue is hard to find in the web: Of course, we did some web research to find out if someone else might have a similar problem, but we did not find very much useful. The mentioned threads have started in February/March 2009 – did nobody suffer from this bug earlier than that? Why did nobody post this issue anywhere before?
• the fact that this version is buggy hasn't been reported on Spring Source web pages: Since it's rather threatening, why not put an eye-catcher message on the download page (or somewhere else) telling that this version is buggy and should not be used?

I can see two reasons for this situation, and actually I don't like both: on one hand, there seems to be no load testing by Spring Web Flow team before doing a release; on the other hand, this version 2.0.5 is probably not used very much for real-world web applications by the community out there, and I honestly hope that this is not true to SWF as a whole...

Read More

Sonar is SO cool!

Do you know Maven? Then you know the project site that can be easily generated with Maven. For instance, look at the site for the Tomcat Maven plugin. It provides information on using the plugin, project related information and – probably most importantly for most "normal" (i.e. non-plugin) projects – the project reports.

You can easily configure Maven to execute a number of useful reports like JavaDoc, Checkstyle, PMD (coding rule verification), CPD (duplicate code detection), and JUnit test coverage. Additionally, you can install custom reports to also participate in project site.

This is great, but still lacks some features:

• What if you would like to see overall code quality, without having to consult several detailed reports? Just a single, combined indicator?


• With the reports, it's not always easy to drill down a particular issue up to source code level.


• It would be nice to be able to access historic versions and compare quality between them to early recognize trends, wouldn't it?

All this (and more) is provided by Sonar (http://sonar.codehaus.org/), an open source tool that "enables to collect, analyze and report metrics on source code. Sonar not only offers consolidated reporting on and across projects throughout time, but it becomes the central place to manage code quality."

Sonar collects data provided by well-known Maven reports, stores them into a database, and provides a modern, fast and convenient user interface to browse the projects and quality metrics, and to drill down from project to Java code level.

Just look at the screenshot of an internal test project... how cool is that?



Installation is as simple as it can be. You can use Sonar with provided Jetty or install it in your existing container. For production, you can switch from embedded Derby database to a "real" database (like MySQL, Oracle, SqlServer, ...). Of course, you can adjust the rules to be checked or import your existing configuration (for Checkstyle or PMD).

To send data to Sonar, you just execute a Maven command to call a particular sonar-maven-plugin for your project:

mvn clean install org.codehaus.sonar:sonar-maven-plugin:1.6:sonar

That's it... now watch all the magic going on.

This Maven goal can be called manually, but is best integrated with nightly builds. To further simplify this, there is a Sonar plugin for Hudson, my favorite continuous integration engine. Using this nice plugin, configuration of a Job to connect to Sonar is as simple as clicking a checkbox in post-build section!

Sonar is so great I really wonder why I didn't find this tool earlier – current version is 1.6, so it must have been out for a while... You definitely should give it a try!

Read More