Plexus Container Annotations and Maven 2 Mojos

I’ll make it short: it’s a mess. You can’t use plexus container 1.5-tooling (with java annotations), if you have to load your components in a plexus 1.0.x-container – which is the case, if your components are utilized in a Maven 2.2.x Mojo. This is simply because plexus container 1.5.x uses “default” as a default role-hint, while NULL is the default in plexus 1.0.x.

But you can use the old tooling, plexus-maven-plugin. But by default it fails if it sees any annotation in your source code, because it uses a version of qdox that doesn’t know annotations yet.

Also, when generating the component descriptor it doesn’t merge with the manually defined one in src/resources (the new one does).

And since, by default, the merge-descriptors goal runs before descriptor (generate) goal, you have to do some back flips to get that running too.

Well here is a configuration that works. At least in my project. Today.

        <!-- descriptor config -->

        <!-- merge config -->

Note: If you only want to use automatic descriptors, remove all <configuration>…</configuration> contents. The defaults will work then.

You can define that in build/pluginManagement/plugins in your parent pom. Then in your project pom, you just put these four lines in build/plugins:


Create branches with Maven Release Plugin (SVN)

I’m currently working on Azure and web packaging (MSDeploy) support for NPanday. I want to do that on a separate SVN branch, which I’ll then reintegrate later on.

The current trunk version is 1.4.1-incubating-SNAPSHOT, and since we are about to release that upcoming version 1.4.1-incubating soon, I don’t want to pollute it with half-baked changes, while I’ll still need to develop on the trunk in parallel.

I’ll also need to be able to install both the current trunk and my experimental branch in my local Maven repository at the same time, hence I need a new temporary version for my branch. All this can be achieved using the Maven Release Plugin, in particular the branch goal. Maven Release supports 14 SCMs through the same interface; in this case we use SVN, though.

What I want


The command I need to run

mvn release:branch 

Lets go through the settings line-by-line:

mvn release:branch

Loads and executes the branch-goal from the Maven Release Plugin.


The name for the branch to be created. When on trunk, Maven figures out to use the default SVN layout for branches and tags. You can optionally define the branch base using the parameter branchBase like this: –DbranchBase=


When ran, Maven will prompt for the version to be used in the branch. I provided 1.5.0-azuresupport-SNAPSHOT. Since autoVersionSubmodules is set to true, Maven Release will automatically use this versions for all submodules and hence also update all inner-project dependencies to that version.

The next four settings go hand-in-hand.


By default, Maven Releases creates intermediate commits to the current working copy. I’m not sure of the reason, but I think it was because some VCS do not support branching/tagging of modified working copies. This parameter makes sure, no intermediate commits are made to the working copy.


With SVN, by default, tags are created remotely. If you want to ommit intermediate commits, this must be set to false.



When branching, you can either define new versions for the current working copy, or the new branch, or both. As set here, the working copy will be left alone, and the plugin will ask for a new version for the branch.

Now I can switch forth and back between the trunk and the new branch, but still build and deploy artifacts side-by-side.

Defaults in POM

You may also provide the fixed values in the POM. And if you want to avoid interfering with other Maven Release actions, you might want to use a profile.


Now it will be enough, when I run mvn release:branch –DbranchName=1.5.0-azuresupport

Recent publications

A while since I posted about articles I wrote. If you know German, this might be interesting for you 🙂

Just a short translation of the topics:

  • Deklarativ bauen: About building .NET applications declaratively with Apache NPanday + Maven.
  • Vom Patch zum Committer: About enabling a good workflow for submitting patches to SVN-based OS projects using GIT, github and GIT-SVN.
  • Quellen anzapfen: Introduction to GIT and GIT-SVN
  • Aschenputtel ausstaffieren: About creating high-quality console applications.
  • Neuigkeiten zum Resharper 5: A “news” article on the history of refactoring tool support and JetBrains newest (at that time) ReSharper version.


July 2011

Bildschirmfoto 2011-06-10 um 14.15.52

Deklarativ bauen, Maven und NPanday, dotnetpro 07/2011, Seite 30

February 2011

Bildschirmfoto 2011-06-10 um 14.16.59

Vom Patch zum Committer, Open-Source Workflow mit Git + SVN, dotnetpro 02/2011, Seite 106

January 2011

Bildschirmfoto 2011-06-10 um 14.16.31

Quellen anzapfen, Einführung zu Open Source, git und git-svn, dotnetpro 01/2011, Seite 84

November 2010

Bildschirmfoto 2011-06-10 um 14.17.45

Aschenputtel ausstaffieren, Konsolenprogramme, Clean Code, dotnetpro 11/2010, Seite 56

September 2010

Bildschirmfoto 2011-06-10 um 14.17.28

Die Schlange im Tigerkäfig, Ko- und Kontravarianz in C#, dotnetpro 09/2010, Seite 68

April 2010

Bildschirmfoto 2011-06-10 um 14.18.50

Neuigkeiten zum ReSharper 5, dotnetMagazin +

NPanday 1.3-incubating released under Apache Incubator (Maven + .NET)

UPDATE: 1.3-incubating was removed from our main npanday site again! We forgot to ask the Incubator PMC for a vote, so we had to withdraw the official release.

The direct links provided in this post still work though.

Stay tuned for 1.3.1-incubating to be released soon! This will then be moved to group id ‘org.apache.npanday’ and deployed into Maven Central.

We are pleased to announce our first release of NPanday under Apache Incubator! NPanday moved from Codeplex to Apache Incubator last year.

Don’t mind the “incubator” in the version. NPanday is stable, allthough we hope to move from incubator into a full Apache project as soon as possible.

What is NPanday?

NPanday brings Maven to .NET (and Mono). It offers a set of plugins to build and test projects, and it defines all the necessary packaging types for deploying and resolving .NET artifacts.

Apache Maven comes with a great infrastructure for dependency management, artifact transport, artifact repositories, release flows with scm-integration, and much more. If you don’t know Maven, go read here. Maven is great!

There is also a Visual Studio 2005/2008/2010 Integration for English Visual Studio installations.

Why NPanday, now there is NuGet

Wrong question. Competition is great. Sad though, that at least some of the originators for NuGet didn’t even know about Maven and NPanday.

Maven is an ecosystem grown over almost 10 years. It has much more to offer than auto-download of dependencies. Still I think we need to integrate the dependency-resolving and deployment part with nuget and nuget-gallery (See future plans).

What is new in this release?

NPanday now supports .NET 4.0 and Visual Studio 2010. There has also been major internal improvements. The PAB and UAC directories where removed. Now NPanday uses a clean maven local repository. This also removed the necessity for custom additions to the install and deploy phases – which where duplications of the corresponding maven plugins.

Read the full Release Notes for NPanday 1.3-incubating

What are the future plans?

On short notice we will release 1.3.1-incubating, which already has 9 resolved issues and only one left to be fixed.

At the same time we are working on version 2.0, which is a huge internal change. NPanday uses a internal RDF database where it keeps additional information for artifacts and dependencies. This is obsolete, but lots of work to remove.

We also want to lead NPanday to more .NET-like conventions for directory structures i.e., while still maintaining the Maven-influenced layout.  Of course we also try to improve stability, ease of use and documentation.

My agenda for NPanday:

We are 4-5 active committers from which 2 work full-time on NPanday as of today. We would really like to get more committers involved. Find out on how to develop NPanday in the NPanday Developer’s Guide.

Where do I get it?

You’ll find everything you need here: NPanday – NPanday Overview

Downloads: NPanday – Download

Current Docs: NPanday – Documentation

Java? Come on! :)

I’m working on a patch for Maven Release. Now Brett asked me to write an integration test, to prove I’m actually fixing something.

The project uses Maven Verifier, which runs a pom and then lets you test whether it did the right thing or not by checking the build log.

Check, if a file has a string in it

I copied this java-code (verify.bsh) from a similar integration test. It reads the build.log and checks if it contains some string.

import java.util.*;
import java.util.regex.*;

    File buildLog = new File( basedir, "build.log" );
    System.out.println( "Checking logs.." );
    StringBuffer data = new StringBuffer( 1024 );
    BufferedReader reader = new BufferedReader( new FileReader( buildLog ) );
    char[] buf = new char[1024];
    int numRead = 0;
    while ( ( numRead = buf ) ) != -1 )
        String readData = String.valueOf( buf, 0, numRead );
        data.append( readData );
        buf = new char[1024];
    String contents = data.toString();

    String expected = "Executing goals 'clean verify' with arguments '-P profile-in-parent,it-repo'";
    if( contents.indexOf( expected ) != -1 )
        return true;
catch( Throwable t )
    return false;

System.out.println( "FAILED!" );
return false;

I now replaced this with following groovy code (verify.groovy):

expected = "[INFO] Executing goals 'clean verify' with arguments '-P it-repo,profile-in-parent'"

println "Expects \"$expected\" in build.log"
println "Checking logs..."

found = new File(basedir, "build.log" )

println found ? "GOOD!" : "FAILED!"

return found

Happy coding!

NPanday 1.2 released – Apache Maven for .NET

The NPanday team finally released NPanday 1.2, coming with quite a few fixes and also some features. In total there were 55 issues fixed. You can find the release notes here. The download is found at CodePlex.

If you haven’t heard of NPanday yet: It brings Apache Maven to the .NET world. In addition to numerous maven plugins for various .NET-related build tasks it comes with a Visual Studio Addin as well.

Major Improvements

  • Compatible with Maven 3
  • MSI-based installer for the Visual Studio AddIn
  • Improved Mono-compatibility
  • Improved Documentation
  • Many bug fixes
  • Improved type names… dotnet-library instead of library, e.g. (NPanday – Project Types)

Hidden Features

We have also implemented two almost undocumented features. We are not yet sure about how those will evolve, that’s why we don’t make noise here…

  1. There is now a custom-lifecycle-plugin that registers the NPanday Types, but only binds the install and the deploy phases. You can then configure plugin executions as you need them in the project pom.
  2. <plugin>
  3. The new type dotnet-archive allows you to package and reference dotnet libraries along with their satellite assemblies, debug symbols or other necessary files. When resolving a dotnet-archive dependency you can use unpack-dependencies to get the files, and for packaging them up, you want to use the Maven Assembly Plugin. For future releases we tend to implement native support for dotnet-archive.

Planned for next releases

  • Support for .NET 4
  • Code Coverage with NCover
  • Localized Satellite Assemblies
  • Update everything to the new types (dotnet-*)

You may want to read Brett Porters’s post as well: NPanday 1.2 Released – .NET integration for Apache Maven