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

Eclipse: Update Manager Fools Me

Recently, we experienced an issue with a custom Eclipse plugin developed and hosted by my company. When trying to install the plugin into various versions of Eclipse Ganymede, the update manager always told me "Cannot find a solution satisfying the following requirements org.eclipse.ui [3.4.2.M20090204-0800]".

Finally, after some lost days of searching and trying, we discovered that this message is totally misleading: the issue was not caused by the feature org.eclipse.ui missing or being available only with wrong version. Instead, the reason was a misconfigured Manifest file of the custom plugin. It just defined wrong version for the required bundles (oAW, the MDA/MDD generator framework we use).

How nasty is that? Couldn't Eclipse update manager (p2) provide better support? More useful messages? Gosh!

Moreover, Eclipse update manager seems to cache the metadata of remote repositories. That might be nice to avoid network overhead of loading the repository again and again. But... when testing installation of different plugin versions with a local update site, it definitely gets into your way. The sad thing is, you can't get rid of the cached contents easily. You'd have to remove the site, restart Eclipse with -clean option two times, and after that recreate the location. Could be made easier, really.

Eclipse update manager will once more be refactored in upcoming Eclipse 3.5 Galileo. Folks, don't mess it up again!

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

Maven Documentation: The Missing List

A rather weak talent of Maven is probably its documentation. This is my personal opinion, but it seem to match what other people think. Yeah, it has been gotten better, but there is still some room...

It's not that there is not enough documentation available, it's just that the existing documentation is poorly organized and you often can't find what you need. Moreover, many documents (especially for plugins) are only scratching the surface, not even diving into the important shallows. Or, even worse, they give you wrong or inconsistent information...

Here is just one example: The surefire plugin page for surefire:test goal gives this description for the excludes parameter: "List of patterns (separated by commas) used to specify the tests that should be excluded in testing. (...)". However, the example page for "Inclusions and Exclusions of Tests" shows an example that uses nested elements – wait, what about the commas? So, what do you do? Go ahead and try yourself? I bet this type of annoyance is hitting every Maven newbie sooner or later.

Well, maybe the Maven team should start a coordinated, collaborative effort to improve documentation just like Wikipedia is doing once in a while. Or, better yet, why not move all documentation into some open Wiki and let the community work on what it thinks is missing, broken, inconsistent, badly organized, ...

Well, until then, we have to use what is available. This post tries to list most important pieces of online documentation, indispensable when you are dealing with Maven in a professional way. Let me know if you think something is missing on this list...

Introductory & General

• Main Site for Apache Maven project
• Maven Getting Started Guide – intended as a reference for those working with Maven for the first time
• The Maven 2 tutorial – a practical guide for Maven 2 users from Codehaus
• offical FAQ and unofficial FAQ
• Sonatype's Summary of Maven How-Tos
• List of Web Tutorials (How-To's)

Books

• Maven: The Definitive Guide – a free book by Sonatype (using a Creative Commons license). High quality, up-to-date, written by some of the famous Maven gurus: Tim O'Brien, John Casey, Brian Fox, Bruce Snyder and Jason Van Zyl.
• Better Builds with Maven – another free book, originally maintained by Mergere, now managed by MaestroDev. This, too, is written by core members of the Apache Maven Project: Vincent Massol, Jason van Zyl, Brett Porter, et al.

Technical Details

• Maven plugins
• Maven Plugins – lists the core plugins (supported by the Maven projects) and others
• Mojo Project Plugins – hosted at Codehaus repository
• Cargo Maven Plugin – used to start/stop J2EE containers and deploy to them
• Docbkx Maven Plugin – hard to find, but useful for generating HTML/PDF from DocBook
• The POM
• POM Reference
• Technical Project Descriptor and POM Schema
• Other important references
• Directory Structure – description of the standard directory layout
• Build Lifecycle – lifecycle basiscs and bindings
• Maven Properties – a list of properties available in Maven 2

Community

• Maven User List, hosted at MarkMail
• Maven Developer List, hosted at MarkMail
• Maven Project Issue Tracking (Jira)

Other Useful Links

• Maven Central – official Maven 2 repository
• MavenSearch.net – search several Maven repositories
• Jarvana search engine (Beta) – Maven-focused Java class and archive search engine
• Maven POM Report – verify if the dependencies in your POM are up-to-date

Updates

• 2009/05/11: added link to Sonatype's "Summary of Maven How-Tos" blog post – definitely worth to be listed here...
• 2009/05/28: added link to Maven Properties Guide wiki page

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

Eclipse: User Operation is Waiting, and Waiting, ...

I am using Eclipse since quite a long time, sometimes around 2002. That was version 2.0, if I remember correctly. Since then, I have always upgraded to the latest version, if not milestone build. Most of the time I was quite happy with the stability and really appreciated all the evolving features and UI improvements.

One major improvement (it was in 3.0, right?) was when they moved builds to a background process, enabling you to continue working when the class or project needed to be compiled.

But... what is this? In all the latest release versions (3.4.0 ... 3.4.2) I sometimes get this dialog when trying to save a file:

Eclipse can't save my file while it is building "in the background"? Come on! Nota bene, I am not talking about .project files or other stuff the whole build could depend upon, it's also true for simple resources or even documentation files!

That's really annoying. This is a modal dialog, which means I have to wait for minutes until build is complete or at least in a state where Eclipse thinks it can save the file. Of course, the user interface is blocked during that time... unless you cancel the save task.

I use the Eclipse Java EE package and additionally have installed a couple of regular plugins, like m2eclipse and oAW. So I can't tell for sure who is actually causing this mess, but on the other hand my installation is probably not so unusual and I'm sure others get this issue as well. There are some entries in various issue databases telling me that I'm right.

Eclipse is great and I (still) love it – but our relationship really gets poisoned by this kind of things... Maybe I try IntelliJ IDEA or NetBeans one day... I have warned you!

Read More

Maven Setting for Using a Single Repo Manager

In a previous post I have tried to explain why it's a good idea to define your Maven repository in your settings.xml file instead of the POM.

Of course, there is some information available on how to do this, for instance in the Maven Settings Reference, the Mirrors Guide, or the great Nexus book from Sonatype.

Nevertheless, this setup of repositories, proxies and mirrors can be a bit tricky (and is quite confusing when just starting with Maven), so here is how we did that.

How should it look like?

We use the Nexus repository manager and especially do like the repository groups which combine repositories into single logical repo. (This feature is also implemented by other products like Archiva or Artifactory, see this Feature Matrix).

Now, here is the approach we want to implement:

• Access the repository group "internal" for release and snapshot versions of all internal artifacts that have been produced by our company
• Use the "public" repository group to provide release versions of all external artifacts (we don't want external snapshots!)
• For downloading plugins, use both the "public" as well as the "internal" repository group to get release versions (we don't want to use snaphot version of plugins!)
• Don't use any other repository than "public" or "internal", no matter what is configured in project's POM, inherited POM, transitive dependencies, dependencies of plugins, etc. -- never ever!

Defining the Repositories

This is the required repository definition:

• We use a profile (that is activated by default) to group the repositories. This is actually not required, but gives a bit more flexibility.
• For artifact resolution, there are two repositories with id "central" and "internal" to provide public (external) respectively internal artifacts.
• The definition for "central" repository is overriding (by using the same id) the "central" repository already defined in the implicit super POM, which is using repo1.maven.org for downloads.
• The given URLs are only bogus and are overridden by mirror settings – see below.
• Additionally, we define the same two repositories "central" and "internal" as plugin repositories (required by Maven to find plugins). However, in contrast to artifacts, snapshots are not allowed at all.

And here is how the code looks like:

<profiles>
  <profile>
    <id>repo-config</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>

    <repositories>
      <!-- repo "central": override Maven default,
           mirrored to Nexus group "public" -->
      <repository>
        <id>central</id>
        <url>http://central</url>
        <releases>
          <enabled>true</enabled>
          <updatePolicy>never</updatePolicy>
          <checksumPolicy>ignore</checksumPolicy>
        </releases>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
      </repository>
      <!-- repo "internal": provides internal release and snapshot artifacts,
           mirrored to Nexus group "internal" -->
      <repository>
        <id>internal</id>
        <url>http://internal</url>
        <releases>
          <enabled>true</enabled>
          <updatePolicy>never</updatePolicy>
          <checksumPolicy>ignore</checksumPolicy>
        </releases>
        <snapshots>
          <enabled>true</enabled>
          <updatePolicy>always</updatePolicy>
          <checksumPolicy>ignore</checksumPolicy>
        </snapshots>
      </repository>
    </repositories>

    <pluginRepositories>
      <!-- plugin-repo "central": override Maven default,
           mirrored to Nexus group "public" -->
      <pluginRepository>
        <id>central</id>
        <url>http://central</url>
        <releases>
          <enabled>true</enabled>
          <updatePolicy>never</updatePolicy>
          <checksumPolicy>ignore</checksumPolicy>
        </releases>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
      </pluginRepository>
      <!-- plugin-repo "internal": provides internal plugin releases,
           mirrored to Nexus group "internal" -->
      <pluginRepository>
        <id>internal</id>
        <url>http://internal</url>
        <releases>
          <enabled>true</enabled>
          <updatePolicy>never</updatePolicy>
          <checksumPolicy>ignore</checksumPolicy>
        </releases>
        <snapshots>
          <enabled>false</enabled>
        </snapshots>
      </pluginRepository>
    </pluginRepositories>

  </profile>
</profiles>

Defining the Mirrors

After defining the repositories, two issues are left: we have to specify the correct URLs, and to make sure nobody uses any other repository. Both of this is done with the <mirrors> definition.

• Repository with id "internal" is mapped to the URL of the "internal" Nexus group; that is, Maven uses that URL instead of what is given with the repository definition (the bogus URL http://internal).
• Every other repository (specified by using <mirrorOf>*</mirrorOf>) is mapped to the URL of the "public" Nexus group.
• This last definition not only maps the "central" repository to the correct URL, but also any other repository and hence ensures every request is locked down to the internal repository manager.

Again, here is the section from settings.xml file:

<mirrors>
  <mirror>
    <id>nexus-internal</id>
    <name>Nexus internal repository group</name>
    <url>http://our-nexus-server:8081/nexus/content/groups/internal</url>
    <mirrorOf>internal</mirrorOf>
  </mirror>
  <mirror>
    <id>nexus-public</id>
    <name>Nexus public repository group</name>
    <url>http://our-nexus-server:8081/nexus/content/groups/public</url>
    <mirrorOf>*</mirrorOf>
  </mirror>
</mirrors>

What about the Proxy?

The <proxy> section in the settings.xml file can be used to define a network proxy that is used for some or all of your HTTP requests. In our configuration, since the Nexus repository manager is running on an internal server and Maven is configured to not connect to any other server, we just don't need this setting.

See Configuring a proxy for more details on Maven Proxies. BTW, it should now be very clear that mirrors in the Maven world are something completely different than proxies...

Read More