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 lifeycle 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 idential 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>[2.2.0,)</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!

After a short hiccup with the distribution location, Maven 2.2.0 has been released and is appearing on most mirrors. John has blogged some details of the changes you can expect in the release. I’ve been using it (and the prior release candidates) daily without any issues, and it does provide some useful changes that make the upgrade worthwhile.

Though it was not a major release in terms of feature changes and fixes, it has helped in re-balancing the available Maven releases in a way that will hopefully be simpler to move forward with and easier to understand.

Maven has suffered for some time with confusion over the “2.1″ version number – some projects still depend on pre-release code from early development on it that ended up not reflecting the 2.1.0 release at all. So along with good reasons to bump the minor version because of build-affecting changes and a firm requirement on Java 5 to run Maven, moving past the confusing version (which is also quite similar to 2.0.10, the other current release) is helpful.

As John has pointed out, 2.2.x is expected to be our stable branch going forward for the near future. We have been extremely paranoid about backwards compatibility between versions for some time, and now feel that we’ve reached a point where development can end on 2.0.x (either at the current 2.0.10 release or with a wrap-up 2.0.11 release that is under discussion).

So that leaves the active tracks as:

• Maven 2.2.x – selective bugfixes on the stable release
• Maven 2.3 – if new features for Maven 2 start being implemented, they will land here in the short term. No roadmap has been defined yet, but there are some open issues in JIRA that could be a starting point
• Maven 3 – a backwards-compatible refactoring of the entire codebase – currently early alpha, developer only, to be released When It’s Done

All users should be able to upgrade to 2.2.0 from 2.0.x, with the small caveats that are documented in the 2.1.0 and 2.2.0 release notes (and if not, be sure to let us know!). So, if you are using Maven 2.0.x, give Maven 2.2.0 a spin!

With so many relatives, friends and co-workers overseas, we were always going to need to share a lot of photos to keep everyone up to date on Samantha as she grows up.

While I had taken a lot of photos over the first two weeks, I’d missed a couple of days, and once she came home it became harder to remember to grab those moments.

When a friend suggested I try one of those “365 projects”, to take a photo every day, I thought it was a great idea to give us some later comparisons and maybe get better at photo taking habits, if not photography itself. So, I went ahead and set up a set for the project.

Now 30 days in, you can already see how she has changed, where day by day it slips past you.

I do wonder what a difference it will make growing up with a life chronicled online, compared to the 1 or 2 photo albums I have to record my first 10 years or so. We need to avoid too many “embarrassing” baby photos that might show up in Google (or successive technology) in 20 years.

But for now it is a great way to keep in touch despite some great distances.

The Selenium Maven plugin 1.0 has now been released, taking advantage of the recent Selenium 1.0.1 release. This will be useful to those using Firefox 3 for example which required a workaround in the previous version.

This is the first stable release version of the plugin. Full credit goes to Jason Dillon for his work on the plugin to get it to this point!

I will be following up with some posts on some tips for its use in the coming days.

In the mean time, here are the release notes since 1.0-rc-1:

Bug

• [MSELENIUM-20] – Starting the selenese goal using selenium-maven-plugin
• [MSELENIUM-39] – firefoxProfileTemplate parameter does not work
• [MSELENIUM-43] – Invalid constructor used by selenese goal to construct SeleniumServer
• [MSELENIUM-49] – Invalid dependency version for ‘org.openqa.selenium.client-drivers’ in site example

Improvement

• [MSELENIUM-30] – Add displayPropertiesFile support for selenium:selenese goal
• [MSELENIUM-40] – Using a remote selenium server with Selenese.
• [MSELENIUM-50] – Upgrade to Selenium 1.0

New Feature

• [MSELENIUM-38] – Start Selenium Server with a Proxy via System Properties

I’ve recently been asked a couple of times how to configure the request parameters for Maven’s outgoing HTTP requests.

The configuration are all added in the server element in settings.xml, in exactly the same way that you would add a password for a deployment repository, for example:

<servers>
  <server>
    <id>central</id>
    <configuration>
      <!-- configuration goes here -->
    </configuration>
  </server>
</servers>

Note that the id must match that of the repository being used, with the default built in to Maven being central. However, if you use a repository manager (and you should!), the id must be that of the mirror, not the original repository. For example:

<servers>
  <server>
    <id>archiva.localhost</id>
    <configuration />
  </server>
</servers>

<mirrors>
  <mirror>
    <id>archiva.localhost</id>
    <url>http://localhost:7777/archiva/repository/releases</url>
    <mirrorOf>external:*</mirrorOf>
  </mirror>
</mirrors>

So what configuration is available?

useCache (Maven 2.0+) – if false, set the Pragma: no-cache header (for HTTP proxies). Default: false

Example:

<server>
  <id>archiva.localhost</id>
  <configuration>
    <useCache>true</useCache>
  </configuration>
</server>

timeout (Maven 2.1+) – the connection timeout in milliseconds. Default: 60000.

Example:

<server>
  <id>archiva.localhost</id>
  <configuration>
    <timeout>5000</timeout> <!-- 5 seconds -->
  </configuration>
</server>

httpHeaders (Maven 2.1+) – additional or overridden HTTP request headers

Example:

<server>
  <id>archiva.localhost</id>
  <configuration>
    <httpHeaders>
      <property>
        <name>User-Agent</name>
        <value>Internal-Build-System/1.0</value>
      </property>
    </httpHeaders>
  </configuration>
</server>

More configuration parameters can be found by examining the available setters for the Wagon implementation in use. For example:

• Lightweight HTTP Wagon (default prior to Maven 2.2.0)
• HTTPClient Wagon (default from Maven 2.2.0 onwards)

It should also be noted that the above technique works for other protocols, using the configuration available for the respective Wagon implementation in use, and also applies to any deployment if the id matches (note that in this case, the mirrors section is not relevant, so it will need to be configured for each deployment repository identifier).

An entirely separate option, if you are using Maven 2.1.0+, is the number of allowed concurrent download threads to use. This is configured via the maven.artifact.threads system property, as described in the configuration documentation.

I feel that I need to start this post with a disclaimer – this is for exceptional use cases only! In particular, take caution:

In any of these cases, it’ll result in a transitive closure that won’t be resolvable if the project is deployed into a repository without copying the repository module around

Over the course of time, the question about why not to store dependencies in version control when using Maven has faded as users have recognised the benefits of having a repository (and particularly a repository manager) in place to maintain their artifacts in a specialised way for the purposes of reuse and reproducibility.

But what happens when that case occurs where that is not practical, such as Greg pointed out in this issue, where you can’t get a repository installed yet but need those dependencies?

A commonly used solution is to have a series of install:install-file executions that manually install the files into the local repository for the build, either using a shell script or very convoluted POM. However, it breaks out of the Maven model of being able to build a multi-module project in one command (or makes it unnecessarily complicated to do so). An example of what results can be seen in the defunct NMaven incubator podling’s bootstrap build.

A better solution is to create a file-based repository stored in version control. By using the native repository mechanism, it ensures dependencies are treated consistently – even if they were to be available from a remote repository in the future. However there can be further problems if you are in a multi-module project. Since it is not recommended to use relative paths outside of the current project, having a single repository for a multi-module build could be complicated again.

The solution I proposed is to create a repository module specifically for housing these special dependencies. This can be included in the build like any other module, and simply needs to be listed first to guarantee that it is built before any other modules. Let’s see how this might look.

Say we have a parent pom.xml:

<project>
  <groupId>com.example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0-SNAPSHOT</version>
  ...
  <modules>
    <module>repository</module>
    <module>modules</module>
  </modules>
</project>

The repository/pom.xml file would then be similar to this:

<project>
  <parent>
    <groupId>com.example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0-SNAPSHOT</version>
  </parent>
  <artifactId>repository</artifactId>
  ...
  <dependencies>
    <dependency>
      <groupId>ancient-artifact</groupId>
      <artifactId>ancient-artifact</artifactId>
      <version>3.1.0.2</version>
    </dependency>
  </dependencies>
  <repositories>
    <repository>
      <id>local</id>
      <url>file:${basedir}/src/repository</url>
    </repository>
  </repositories>
</project>

Here we can see that the dependency (stored in repository/src/repository/ancient-artifact/ancient-artifact/3.1.0.2/ancient-artifact-3.1.0.2.jar) is self-contained to the repository module, and guaranteed to be installed when that project is built. Since it is listed first in parent build, the local repository will be correctly populated before any other modules are built. What’s more, if the dependencies are already present locally this module will skip by extremely quickly.

Note: if you happen to use this technique and also have a repository manager configured using Maven’s mirrorOf settings directive, make sure that you use <mirrorOf>external:*</mirrorOF> to ensure that the file-based repository requests are not passed to the repository manager.

A more complete example can be seen in the project attached to MNG-3989.

Now, while this is likely to be of very limited use, I did find it an interesting exercise to illustrate how you can still map alternate workflows neatly into the Maven paradigm, in a way that doesn’t compromise its artifact flow or build lifecycle, and still gives you a path forward to a different configuration with a remote repository storing the artifacts simply by removing the repository module.

This technique may also have additional utility for those with a policy-driven requirement to use their version control to store dependencies for reproducibility purposes, if they can afford the verbosity of restating all those dependencies in the repository POM.

Of course, I would still recommend using a remote repository wherever possible to manage these artifacts, and to treat its contents on the same level as your version control in your infrastructure if you intend to have a long-lived Maven installation. As noted at the beginning, this becomes a requirement if you want to publish your project as something others may depend on. However, if you need to store your dependencies in version control, this technique may help you at least honour Maven practices in doing so and perhaps reduce an initial adoption curve.

When it came to migrate my blog from an older installation of WordPress to the latest version on WordPress.com, I had a problem. The content export was 20Mb, but the limit was 15Mb. The cause was obvious – SPAM comments had filled up the old one (even though marked as SPAM, they are still exported), and until recently there has been no way other than modifying the database to get rid of them entirely. I had hoped to do that from the new system, but I couldn’t get past square one.

To resolve this, I put together this XSLT to remove SPAM comments from your WordPress exports:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:wp="http://wordpress.org/export/1.0/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns="http://www.w3.org/1999/xhtml">
  <xsl:template match="//wp:comment[wp:comment_approved = 'spam']">
  </xsl:template>
  <xsl:template match="//content:encoded">
    <xsl:copy>
      <xsl:value-of select="." disable-output-escaping="yes" />
    </xsl:copy>
  </xsl:template>
  <xsl:template match="*">
    <xsl:copy>
      <xsl:copy-of select="@*" />
      <xsl:apply-templates />
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

Unfortunately, I had to manually go and fix some malformed comment HTML (or in the case of SPAM, just delete it) for it to work, since the XML wouldn’t even parse, but once that was done the result worked perfectly for the import. Then it was just a matter of cleaning up old blog links and some HTML that didn’t look quite right in the new template by searching within WordPress.

I hope someone else finds this useful!

It’s been a busy time of late, and my blog has been much neglected, so it is time to get back into it. I’ve started by re-invigorating it and since I have become used to WordPress, I’ve moved it to WordPress.com. Everything should redirect over there soon, and if you are subscribed to the feedburner URL you will already be reading this there and nothing need to change.

Catch me over at http://brettporter.wordpress.com/ !

Archiva is celebrating its 1-year anniversary of being a top level project at Apache, and fittingly a new release is now available for download.

Some of the new features that are in the latest release:

• Generation of the Nexus index format
• Other search related improvements
• Improved audit logging of changes
• Repository statistics information
• An XMLRPC interface to all administration and search features
• Ability to delete artifacts

A good number of issues with metadata handling and security roles have also been resolved – all of the issues fixed in the 1.2 series are also shown in the change log.

So, what comes next?

We’re already planning a 1.2.1 release to clean up some of the issue backlog and particularly improve the install experience for Tomcat users.

While a roadmap for the next feature release has not been locked down, it is likely some of the experimental development efforts will be folded in, such as:

• Removing the hard dependency on a database ("back to the future" of sorts in that pre-1.0 versions of Archiva worked in this way), making it optional for statistics and querying
• Addition of arbitrary artifact metadata to support alternate repository types
• Re-architecting around an event model for artifacts to make customisation easier
• More automated handling of plugins, with extension points beyond the current "consumer" model for newly discovered artifacts

As always, if you’d like to get involved we’re happy to hear from you at the developers mailing list.