Tag Archives: plugins

NPanday has moved to the Apache Incubator

Just short of two years ago, NPanday was established at Codeplex. It picked up where one of the branches of the NMaven podling had left off, and has since grown into the most stable, popular and comprehensive solution for Maven users looking to build .NET projects.

I wrote more about what NPanday does in the previous post on its 1.2 release, and there is plenty of information in the incubation proposal if this is an area you are interested in.

There were several reasons in my mind for returning to Apache.

The most pressing reason was repeated problems with infrastructure at Codeplex, and in particular the SVN interface they provide over the top of TFS. Failures with creating tags, altering properties, and general timeouts and weird errors were holding up releases and development (extracting the history from this was also an “interesting” exercise, and the subject of a future post).

Apache provides not only the infrastructure but the governance structure to best support and “future proof” a growing community. We had recently added two committers in Lars and Craig, and have been seeing regular patches from other contributors. The Codeplex stats showed that we had thousands of downloads and visitors, not including traffic directly to the Maven repository. This growing community has given me confidence that the project will move quickly towards a successful graduation.

Moving isn’t a quick process (now at two months since the original proposal), and thanks go to our users for bearing with us. We’re still in the process of moving infrastructure, with the following set up:

We’re still working on migrating the web site and issue tracker.

Back to the code, there’s plenty of work to do, and discussions on the next features and changes have started on the new list. If you’re interested in a Maven-like solution for building .NET projects, or working in a hybrid Java-.NET environment, we’d like to hear from you! We’re particularly interested in working with folks that can help improve the C# portions of the code, including the Visual Studio Add-in.

If you’re one of the many users out there, what do you think of the move?


Selenium Maven Plugin 1.0.1 Released

The Selenium Maven plugin 1.0.1 has been released, to correspond with the recent Selenium 1.0.2 release. Mac & Firefox users rejoice!

Here are the changes that were included:

  • [MSELENIUM-59] – Selenium server could not be stopped from stop-server goal
  • [MSELENIUM-60] – Fails to run with Firefox 3.5 on OS X 10.6.2
  • [MSELENIUM-58] – docu is outdated: there is no parameter multiWindow anymore

Updated Multi-module Support for Maven Release Plugin

Last week Dennis started things moving to have another release of the Maven Release Plugin. The release process should start very soon, so please join us on dev@maven.apache.org to help test it!

This is certainly a nice one to have out the door, not only because of the length of time since the last release but because it fixes some important bugs (Subversion 1.6 support for starters), and improves multi-module support.

Having been bitten by the latter category myself very recently I took the opportunity to get a couple of changes in.

Support for flat directory multi-module projects

This highly requested support was actually added by Deng way back in May last year, but it was only recently that I started using the new version of the plugin and discovered a small corner case I jumped in and made a couple of improvements and fixes.

While I would always recommend using a typical hierarchical Maven multi-module project, there are a number of existing projects using the flat structure, particularly in non-Java environments. It’s good that the release plugin can now support anything with a common trunk.

This means that projects like the following will now release correctly (run from the parent directory):

|-- release-parent
|   `-- pom.xml
|-- release-module2
|   `-- pom.xml
`-- release-module1
    `-- pom.xml

Not requiring artifacts to be in the local repository before releasing

This controversial issue has popped up a number of times and proven to be a real nuisance in releases, where a multi-module project needed to be built locally before it can be released (including the preparation test, that makes 3 full builds!), or at best spouted a large number of warnings about missing dependencies on the artifacts it was yet to build.

In the end here we decided to revert to the original behaviour and accept the limitations that came with, while making the typical release faster and easier. The release:prepare-with-pom goal has been added to cater to the use case for which the dependency resolution was put in place originally. With this intended to be the 2.0 release of the plugin, we can stick to this behaviour going forward.

In the future, Maven 3.0 has added additional capabilities for plugins to operate with their modules without building them first, which will allow a unified and enhanced release:prepare goal once more, but in the mean time we’ve opted to put in place the best solution for the majority of Maven users today.

Apache Maven 2: Effective Implementation Sample Chapter

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:

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!

Selenium Maven Plugin 1.0 Released

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:


  • [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


  • [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