Ken Cavanaugh had passed away

I’ve just learned that Ken Cavanaugh had passed away. He was my colleague back in Sun, and we had worked on a few small projects together.

When I joined Sun, he was already THE CORBA guy AFAIK, and when I left Sun, AFAIK he was still THE CORBA guy. And I was at Sun for, like 8 years. Not many people have a passion that lasts that long for any given field of technology, and that left me a rather strong impression. I always hoped that I could be like that when I get to his age.

Certain people emits an aura of confidence/reassurance. You can tell right away that he knows what he’s doing/saying when he does/says something. Ken was one of such people for me. He thus obviously commanded the respect he deserves, and you can see it in the guest posts that his colleagues left on his website that that’s not just me. I can really only use English well enough for dry technical matters, so I can’t really describe the feeling very well. I’m just very sorry to hear the news.

My epic battle with findbugs-maven-plugin and how I utterly lost

It started quite innoucently. I was looking at this thread in Jenkins dev list and thought it’d be a good idea to get some critical findbugs errors to fail a build. My goal was simple, I want to run some high-priority findbugs checkers during the build, and if they report any error, I want the build to fail. I wanted this to be in a profile, so that I don’t need to wait for FindBugs to finish if I just want to build.

Should be simple enough, you’d think. Nope.

I’ve spent the entire afternoon getting this going. There were several issues in the plugin and relevant places that blocked my progress. In the hope that other people won’t suffer the same loss, here are those:

  • Maven 2.x and Maven 3.x site plugins are totally incompatible, breaking the setup that used to work. AFAIK there’s still no reasonable approach to enable your project to build both with Maven 2 and Maven 3, when it comes to site stuff, and that pretty much includes all the code analysis plugins. Maven 3 breaks backward compatibility with the site configuration of Maven 2, so the POM setup that used to work will no longer work with Maven 3. (So if someone tells you that Maven 3 is compatible with Maven2, don’t let them fool you.) It silently ignores all you have in and does nothing. So you’ll have to move the reporting configuration into a new location. This used to make it impossible to share the site configuration between Maven2 and Maven3, but I was told that the latest Maven site plugin version 3.0 no longer has this problem.

  • Findbugs plugin documentation seems to offer two mojos to generate reports — findbugs:check and findbugs:findbugs. But the check mojo actually isn’t capable of generating any reports. Two dozen or so configuration options to tweak the report generation you see in the doc are totally bogus. They are unused and ignored. (correction 8/24: what I missed is that the check plugin designates findbugs:findbugs as a pre-requisite.)

  • Some people tell you that you can invoke mvn findbugs:findbugs directly to generate report, but this is rather problematic if you actually try it. Firstly, it will generate XML but not HTML, so it’s useless for human beings. It does tell you how many bugs it found, but it doesn’t tell anything that actually points you to where the offending code is. One is supposed to be able to work around that by running the findbugs:gui mojo, but AFAICT this mojo is utterly broken. Secondly, if you invoke findbugs:findbugs mojo directly, it doesn’t pick up the same configuration that it uses during the site generation (one picks up build/plugins/plugin, the other looks at reporting/plugins/plugin). Again, AFAIK there’s no way to have those two modes of invocation use the same configuration.

  • You need to make sure that Maven at least compiled your source code before running site. The FindBugs mojo will happily skip itself if there’s no class files to work on, and unless you are smart enough to figure out what the mysterious “canGenerate=false” line means, you’ll waste your time trying to figure out why the mojo isn’t working, like I did.

  • Remember my use case of making the build fail in case of serious FindBugs issues? Documentation might make you believe that findbugs:check mojo is able to do this, but there are two large pit-falls. One is what I’ve already described, namely that this doesn’t actually run FindBugs, and instead it expects that you’ve already run it. The other is that if it doesn’t find any trace of FindBugs running, it happily skips itself. The consequence is that mvn clean install will always complete successfully, even if your code has FindBugs violations. I still haven’t figured out how to make this whole thing work. As I mentioned, findbugs report generation itself requires that the source code be compiled, so I guess you’d have to invoke Maven like mvn clean compile site install or something. This is just ridiculous.

  • In FindBugs, you can specify what rules you want to enforce and what rules you want to ignore. You describe this in a filter file. In a multi-module project, it tends to be more convenient to have just one filter file that all your modules use, rather than having many similar filter definitions. But this seemingly typical use case just doesn’t work with the Maven FindBugs plugin, because the path you specify in the filter file configuration is always interpreted relative to the current Maven module, and there seems to be no way to have it point to the base directory of the project (the ${project.basedir} macro also expands to the current module’s base directory, which is useless.) The documentation does talk about this and gives you a work around. As a Maven plugin developer myself, I understand where they are coming from, but as a Git user, the assumption that requires such a cumbersome workaround (of being able to check out and build modules individually, like you can in Subversion) is unnecessary, yet I still have to pay all the price. This doesn’t make sense.

I’m sorry to say this, but this is a disaster. Integrating FindBugs in Ant project, generating HTML report, and failing a build in case of significant error is fairly straight-forward, and takes maybe 10 or 20 lines at max. But here in Maven, it takes more lines in your POM, not to mention one whole Maven module just for the filter file, plus all these pitfalls. And it still doesn’t attain my original goal of making critical FindBugs issues fail the build.

Experiences like this made me really want to switch to Gradle, but alas, it’s no longer my call alone to make changes like that. So for the time being, I think I’m going back to my good trusted Maven antrun extended plugin. At least it works. And Stephen, this is why Ant fragment is actually more maintainable than the magical combination of Maven hacks.

Calling for your participation in Jenkins User Conference

By now, you are surely aware of the Jenkins User Conference (JUC) that will be held the Sunday before JavaOne – October 2 – at the Marines’ Memorial Hotel in San Francisco, starting 9:00am PDT. This is a major milestone for the Jenkins Community – our first ever User Conference!

The Jenkins community needs to participate in JUC – certainly as an attendee, but also in supporting the organization and promotion of the Conference. Several vendors are helping to organize this first conference, but I think it’d be good for everyone if this is a community-driven event, and for that the Jenkins Community must play a major role, too.

To that end, I’d like to ask everyone to do the following to support JUC:

  • Register to attend. After all, it’s a free event with lots of useful contents!
  • Speak. People often incorrectly think that they need to be a project insider to be “qualified”, but that’s not the case. Lots of users want to hear about how other fellow users are using the software. So please tell us your showing off how you use Jenkins, clever ways you combine various pieces, technical/organizational challenges you faced, an so on. There are some great suggestions for potential topics on the JUC web page.
  • Recruit. If you aren’t comfortable speaking, please recruit someone else you think has an interesting Jenkins-related topic to present to the Community.
  • Promote the Conference. Even if you can’t come, please Tweet about it, re-Tweet posts you see from the @jenkinsconf Twitter account to your followers, email your friends, post to Facebook, and Like the JUC posts already there. If you paste in the JUC web page URL to your Facebook post, it will automatically pull in the cool Jenkins image we created for the conference. All of these things are easy to do and they really make a difference in getting the word out!
  • Sponsor the Conference. Sponsors are actively being recruited. One of the ways companies can give back to the Jenkins project that they’ve benefited from is by sponsoring JUC. Helping the project flourish protects your company’s investment in the use of Jenkins. All sponsorship levels also defray the costs of the Conference, thus keeping it free for attendees. Maybe your company would consider sponsoring? Hit up your favorite vendor to do so, too!

Registrations are coming in daily. So far, we have about 80 attendees, so please keep them coming. If you haven’t registered, register soon before the seats fill up. Making the event successful opens up many interesting options (like organizing other events in the future, etc), and that way it benefits the community as a whole, not to mention continuing to increase the Community’s knowledge and making Jenkins an even better platform in the process.

I look forward to seeing you there – as an attendee, a speaker, and/or a sponsor! We’ll have some more exciting things to announce in the coming weeks, so stay tuned!