A few Maven committers are going to be at ApacheCon US in Oakland next week, and we’ve organised for a free user and developer meetup as part of the conference schedule. It’ll be held on Tuesday, November 3, at 8pm.

Brian has posted a short signup page, so if you’re planning to come along, please add your name there. You might also want to talk about a particular subject for 15 minutes and add it to the proposed agenda.

There’s still time to sign up for my Maven training course on Monday, November 2 as well, which you can do from the main conference registration page.

Looking forward to seeing you all there!

Better Builds with Maven has been available for a few years now, initially to those who registered on the web site and then available as a freely downloadable PDF. However, now it is finally available to read online as HTML, bookmark, etc. (in addition to the PDF download). It has also been relicensed under a Creative Commons license.

While the book is now somewhat dated and there are newer alternatives available, the information is still relevant. It has had minor updates as it moved homes several times over the last few years.

I hope you find this useful!

As I’ve blogged previously, I’m gearing up again to present my training session Apache Maven: End-to-end at ApacheCon US in Oakland in just a few weeks now. There are still spots available, so go ahead and register from the ApacheCon US site. Noirin offers some tips on how to justify ApacheCon to your boss.

The training session is hands on – all of the software and material is distributed on CDs and we spend some time digging into Maven and development infrastructure in a variety of ways.

Apart from the standard training material, there is the opportunity to work through some specific questions for your environment if it is something that interests the whole group, and of course those discussions can be continued over the rest of the time at the conference.

Hope to see you there!

When I announced the release of the book last week, I neglected to mention that there is a sample chapter online. It is available from the book’s site, but can be directly downloaded as a PDF:

• Chapter 6 – Useful Maven Plugins

There is also an excerpt online if you don’t like PDF.

While it does stand alone, the examples are also worked in to the context of the sample project used throughout the book where appropriate.

This chapter was a late inclusion, but turned out to be one of my favourites. While it doesn’t cover all the useful Maven plugins (many such as the Enforcer and Assembly plugins are picked up elsewhere in the book), it highlights some that aren’t always well known or used:

• The Remote Resources plugin – and particularly the right pattern for including a package of reusable resources
• The Build Number plugin
• The Shade plugin – a very useful way to handle redistributing JARs and “uberJARs” and reducing dependency and classloading issues
• The Build Helper plugin – useful bits and pieces like additional artifacts to deploy and reserved network ports for tests
• The AntRun plugin (and other scripting languages) – how to still use Ant without the guilt of violating The Maven Way!
• The Exec plugin – fork an external process in your build, or configure it for running your standalone application easily from the POM

I do think if there was one plugin I would have liked to cover more in this centralised location it would have been the Enforcer – perhaps pulling some entries together would make a good blog topic in the future though.

I hope you enjoy the sample chapter and consider buying the book!

Last week, Rich Bowen from Feathercast interviewed me about the training I’ll be hosting in Oakland on November 2: FeatherCast » Blog Archive » Episode 63: Brett Porter – Maven. More information about the training session can be found on the conference web site or in my previous post.

It’s that time of year again! ApacheCon US in Oakland is on 2-6 November 2009. There are still discounts for registration by September 25.

I’m presenting my full-day Maven and development infrastructure training again on Monday November 2, called Apache Maven: End-to-end:

This training session will walk through the lifecycle of developing a typical Java application from creation to deployment, and show how to use Apache Maven most effectively to manage the build and development process. In addition to the fundamental building blocks of the project, the session will cover testing, day-to-day development in the IDE, application of Maven best practices, effective dependency management, establishing a release process, using profiles effectively, setting up documentation, tracking development reports and practices. Effective use of continuous integration (illustrated with Apache Continuum) and repository management (using Apache Archiva) as a part of development infrastructure for team and enterprise environments will be demonstrated. This course will be suitable both for those that are looking to get the most out of their existing Maven projects, and those that are looking to use Maven for the first time. Time is reserved for addressing specific situations that attendees have encountered in existing projects.

The material is aimed to offer most to the intermediate Maven user, while still being appropriate for Maven beginners, and is refreshed with the latest work from the book.

After being available in “RAW” (draft) form for the last few months, the final release of Apache Maven 2: Effective Implementation is now available online! It is available in both eBook and printed + eBook versions.

We had some specific goals in writing this that I think we’ve achieved:

• It is intended to build on top of knowledge from the free books that have gone before it with minimal duplication – though still enough information to stand alone.
• The book should be of most value to intermediate Maven users, but also useful to beginners. Everyone should learn something from it. It should update Maven 2.0 users on the latest available technology such as Maven 2.2, the newer Archetype creation from a project mechanism, and under-utilised plugins like the Enforcer or Shade plugins.
• We wanted to focus on “best practices” and tying everything together in a way that shows how Maven was meant to be used. Hopefully readers will experience the occasional “aha!” moment.
• The book works through the issues by a gradual example application, like building up (or applying Maven to) your own project. It intends to show how a reasonably complete project structure is best worked with, and the example application should be relatively interesting in its own right. It gets built from scratch, up to an assembly, building it in CI, deploying it to the repository, and releasing it.
• We wanted to give some coverage to Archiva and Continuum (projects that we’ve both been involved in for some time) to illustrate team concepts, but also convey the concepts in a way that translates to other equivalent tools.

You can see what was covered in the Table of Contents.

The book eventually weighed in at 450 pages – far more than we’d intended when we set out, though still with plenty of potential topics to cover. When we started this just over a year ago, my thoughts had initially been around simply covering the content from my series of Maven presentations and training content in book form, but soon found we could expand on many of the topics.

I had the good fortune to work with Deng Ching on the book (her announcement is on her blog), who poured a number of weekends and evenings into writing half of the content and reading (and re-reading) my writing.

We had some great help from our reviewers – Carsten Ziegler, Wendy Smoak and Emmanuel Venisse, as well as the encouragement of several others who wanted to help but couldn’t commit the time. Thank you all!

Wow, long time between posts… well, no time like the present and I thought I’d share a my notes on the Snow Leopard upgrade in case it helps anyone else.

The rant

Firstly, the obligatory rant. I had a world of pain just getting to the install process. After my initial disc was promptly shipped out, it turned out to be from a bad batch. The first support rep recommended trying again and if it failed to call back and we’d try and archive and install. Luckily the rep that responded when I called back didn’t put me through that and just put me through to order management for a replacement disc. After an hour on hold, it’s quickly sorted out and I’m told it’ll be shipped out in 2-3 days. 3 days later I discover it hasn’t been shipped, and is instead queued for a refund. Another half hour on the phone trying to explain I wanted a replacement because it was faulty, and it actually does get prepared for shipment, arriving the Monday after the first one arrived.

The install

So, armed with working disc, I pressed forward. The install proceeded as advertised – it said it would take about an hour, and it did – up until it got to the “Less than a minute” remaining, which took about… 45 minutes before I gave up. It was apparent it had frozen. No choice but to hard power down. Rebooted and it booted into the Snow Leopard welcome – the install was successful, but I was stuck in the first time set up. Everything I tried left the registration step getting to the end with all the buttons disabled… so, onto the phone with tech support. Started by rebooting in safe mode which took a really long time but didn’t help much. So we stepped through the process anyway. As it turns out…

To skip the registration process, you can use Cmd-Q and select skip.

Not very intuitive, but I guess it discourages skipping it rather than having the button right there in the dialog. So, now I can create an account (must be a new one), and I’m logged in. Everything is still there (*phew*). Reboot into normal mode (takes an eternity to shut down), log in as myself and remove the newly created account. An hour into the call, now I’m all set.

Incidently, during frequent periods of waiting for the Mac to boot / shutdown I discussed the virtues of a clean install with the tech support, but am told that wouldn’t be possible with the Snow Leopard upgrade disc (apparently in contradiction to what I was told by the very first tech support and most of what is said on the internet – curious).

I found I’d freed about 12Gb during the process (measured using df -k to avoid being duped by the redefinition of a Gb) – a handy saving.

Checking it out, I found I had a new /Recovered Items directory which was unusual. I’m not sure if I just got this because of the missed completion of the installer. About 500Mb of data, including some things that didn’t make it (like the XCode tools). I’m holding onto it for now, but it looks like I shouldn’t need it.

Next, to see what survived the upgrade.

The Victims

I was well aware of what might and might not work after the upgrade. Here’s what I’ve found so far:

• XCode command line tools
• Dovecot
• MailTags (upgraded to their 10.6 special version which seems fine)
• Mail Act-On (was using 1.3, may need to pay to upgrade to 2.0 now)
• The sync server in Omnifocus
• The Omnifocus mail integration (re-installed from OmniFocus preferences)
• iStat Menus (upgraded to 2.0, no problems)
• Java 1.3 / 1.4 / 5
• Visor plugin (relies on SIMBL, not re-installing)
• Sort ordering in smart mailboxes in Mail.app is not retained (no fix found yet)
• X-Lite had no sound (upgraded to a beta version that seems to work)

I uninstalled a few other things that I wasn’t using any more to try and get rid of 32-bit system preference panels (though most seemed to be working).

XCode Command Line Tools

Oddly, gcc-4.2 and the other command line tools were moved to Recovered Items but most of the XCode installation survived. I planned to reinstall the new version anyway, which I tried. This failed about halfway through without much information other than to try again, which I did and succeeded. Go figure.

Dovecot

I had recently moved from MacPorts to Homebrew in anticipation of the upgrade, and all continued working afterwards except for Dovecot.

First up, it seems the dovecot user had disappeared during the upgrade process. Luckily, 10.6 seems to have included one by default, _dovecot in the mail group. So I adjusted the Dovecot configuration.

Next, failure to read /private/etc/ssl/certs/dovecot.pem – had just forgotten to use sudo when running launchctl. Try again.

After that, there was a period where it wouldn’t start and gave no error in the system log. To be honest, I don’t know what I did to fix that but when I came back to it later after some reboots it was working again. Reassuring.

Eventually got it started again but failed to auth from Mail.app. The system log showed:

7/09/09 6:37:36 PM	dovecot-auth[82]	in openpam_load_module(): no pam_securityserver.so found
7/09/09 6:37:36 PM	dovecot[80]	auth-worker(default): pam(brett,127.0.0.1): pam_start() failed: system error

Seems that this has been removed in Snow Leopard. I’d been using the /etc/pam.d/dovecot file given here. I used the further recommendation on the page to remove that file and change the dovecot configuration to this:

passdb pam {
  args = login
}

After all that, my local mail server is back.

OmniFocus sync server

This one was a little unusual. The sync server runs a copy of Apache HTTP Server, which was failing to start up. The logs revealed:

[Mon Sep 07 18:36:30 2009] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Mon Sep 07 18:36:30 2009] [warn] RSA server certificate CommonName (CN) `mcbrett' does NOT match server name!?

While the short hostname of the machine was still mcbrett as before, it turned out that my installation pattern had changed the main host name to dummy's MacBook Pro 15" (dummy being the account name I created at first). I decided it was time for a change and changed my hostname to brettporter:

sudo hostname brettporter
sudo scutil --set HostName brettporter

Along with the same change in the Sharing system preferences, this was enough to get the sync server started again.

The Verdict

Other than these, my apps (including some that had received bad reports from others) seem to be working fine.

This was a much more painful upgrade than Leopard (salt in the wounds from the painful ordering process). The disk space saving is nice, but it never lasts So far I haven’t noticed much in the way of performance improvements and have still obtained the marble of doom – time will tell if it seems to have improved or not. I’m particularly interested in Time Machine performance.

The big wins probably won’t come until applications start to take advantage of grand central and so on. All in all that is what appeals to me most about the release – most developers would love the opportunity to take some time and just clean things up in their projects and build out the core support.

Out of curiosity based on current development list discussions, and because I wanted the opportunity to try a WordPress poll anyway, I’m asking the following question:

One of the interesting features that has appeared in Maven 2.2 is the ability to add configuration specifically to the goal execution supplied by default lifecycle bindings.

Previously, you could only do this at the plugin level, for example:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.4.3</version>
  <configuration>
    <excludes>
      <exclude>**/selenium/**</exclude>
    </excludes>
  </configuration>
</plugin>

There are two problems with this:

1. it may not be appropriate for all goals in the plugin to take this configuration. This is a common problem with the Compiler plugin, where you may want different parameters for the compile and testCompile goals (such as the JDK level – a problem well known by TestNG users developing on JDK 1.4!)
2. you can’t erase configuration through inheritance – so as the example above shows, you are stuck with those excludes even if you define a new goal to run a second set of tests

Consider the addition of the following to the above:

<profile>
  <id>selenium</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <executions>
          <execution>
            <id>selenium-tests</id>
            <configuration>
              <includes>
                <include>**/selenium/**</include>
              </includes>
            </configuration>
            <goals>
              <goal>test</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

This will do nothing, since only the Selenium tests are to be run (includes), but all Selenium tests are disabled (by inheritance of excludes).

This leads to a convoluted combination of turning off the default binding, re-adding it with its configuration, as a modification to the first sample:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.4.3</version>
  <configuration>
    <skip>true</skip>
  </configuration>
  <executions>
    <execution>
      <id>unit-tests</id>
      <configuration>
        <skip>false</skip>
        <excludes>
          <exclude>**/selenium/**</exclude>
        </excludes>
      </configuration>
      <goals>
        <goal>test</goal>
      </goals>
    </execution>
  </executions>
</plugin>

The skip flag also needed to be added to the Selenium profile.

Maven 2.2 adds a simple solution to this problem – all of the executions in the default lifecycle are assigned IDs of the form default-phase. Because Maven’s inheritance merges executions with identcial IDs, you can assign configuration directly to the built in goal and no others.

This means that the previous section can be reduced back closer to the original, like so:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.4.3</version>
  <executions>
    <execution>
      <id>default-test</id>
      <configuration>
        <excludes>
          <exclude>**/selenium/**</exclude>
        </excludes>
      </configuration>
    </execution>
  </executions>
</plugin>

The goals are not necessary in the execution, since they were already given in the default binding.

This results in a more intuitive pattern for setting up multiple test executions (a common occurrence with profiles and integration tests), as well as use cases such as configuration the compiler plugin goals separately.

One more thing to watch out for – taking advantage of this will mean the build is no longer compatible with earlier versions of Maven. To make sure you don’t get caught out, you should add the Enforcer plugin somewhere in the build:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>1.0-beta-1</version>
  <executions>
    <execution>
      <id>enforce</id>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <requireMavenVersion>
            <version>[2.2.0,)</version>
          </requireMavenVersion>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

In addition to changing the defaults, you can also now supply configuration that is targeted at command line invocations (without affecting the main build). More information on all of these can be found in the new Guide to Configuring Default Execution IDs.

Enjoy!