Updates on NPanday 1.2 Release

May 22, 2010 at 9:45 AM

Hi All,

Due to some unforseen circumstances, we've decided to move the 1.2 release on May 25, 2010.

Here's the final list of the issues fixed for this release:


09011 - Trunk fails to compile when not having VisualStudio

09019 - java packages not matches with classes package declaration

09622 - error building npanday on linux

09627 - Visual Studio Addin Installer

10276 - Incompatibility between NPanday and maven-flex-plugin

10389 - Specify nunit-console binary for maven-test-plugin

10603 - Build with embedded resource files

10710 - Docs on the Automation of NPanday Startup

10803 - Create Addin Folder during installation if not present

10813 - Migrate relevant wiki content to bundled documentation

11453 - vsinstaller:install does not generate the AddOn when My Documents is not under ${HOME}

11524 - Complete integration tests for wix plugin

11614 - refresh bundled documentation

11615 - migrate integration-tests to npanday-its

11635 - Resync Reference unable to download snapshot artifact from Archiva

11637 - MSBuild output is not shown and errors are ignored

11649 - Add Maven Artifact dialog may not appear if settings can not be read

11673 - GAC versions of NPanday.Model.Pom and NPanday.Plugin are not shipped in the 1.1 repository

11695 - MSBuild Plugin fails to resolve references in a clean environment

11697 - Visual Studio Add-In needs to maintain the includeSources compile plugin configuration

11711 - Renaming a web reference would result to adding a new <webreference> node

11746 - show the NPanday version in console when it starts up, and/or have an about box

11803 - generated ID for remote repository is too long

11837 - VS crashes when adding a new remote repository

11938 - VS-Installer-Plugin only supports english environments

11941 - Doku on Uninstalling NPanday, mscorcfg.msc location

11946 - Update Documentation: Install + Build NPanday locally with VS 2008 only

11949 - Update Documentation: NUnit-Console must be configured or in Env Path

11955 - 1.2-SNAPSHOT referencing 1.1-SNAPSHOT

12004 - Unable to recognised GAC dependencies

12011 - Deploy plugin deploys artifacts with a classifier with a different snapshot build number

12110 - Unable to build VB WebApp projects with a .Net 3.0 Version

12120 - Misleading warning message when unable to resolve an SCM URL

12239 - NUnit doesn't work on Mono

12287 - Overzealous project structure check in project importer

12379 - WiX plugin ITs depend on .NET 3.5 SDK

12402 - Supporting alternative packaging types

12549 - WPF applications can miss including required resources

12686 - Remove the deploy plugin

12782 - NPanday should respect expressions in configs/settings

11480 - NPanday should support MVC

12287 - Overzealous project structure check in project importer

13199 - compile-plugin calls different goals on deploy for ArtifactType.LIBRARY and ArtifactType.EXE/WINEXE

13203 - Completely enable npanday for new dotnet-* types

12231 - Unable to build NPanday projects on Maven 3

13092 - Logger on Resync

13018 - NPanday Transitive Dependency Error

12940 - NPanday Fails to Resolve Dependencies if mixed versions of -SNAPSHOT and Released

12951 - Document how to add intra solution references

12901 - Visual Studio Addin should support <mirrors> in settings.xml


Thank you for your patience and support for NPanday.

May 24, 2010 at 7:46 PM
Edited May 24, 2010 at 7:46 PM
If we want to migrate all packagings to the new dotnet-* types, we can't do it tomorrow.

There is also still one failing integration test:

Tests in error:
--- Problem with .NET Executables from PAB. Plugin-Runner is somehow not found.
May 25, 2010 at 12:15 AM

I guess we should roll it back for now? No point rushing it - we can always release another version as a stepping stone to 2.0 and give this some more soak time

May 25, 2010 at 5:27 AM

If you manage to easily do that. It has man commits and other bugfixes inbetween.
I think it is less work to fix the One bug. And then to not migrate the internal packagings.
Or just live with the bug. I ought to think it is an old one anyway. Maybe it only occurs on my machine?

May 25, 2010 at 7:12 AM

I trust your judgement either way :)

May 25, 2010 at 8:02 AM

OK. Here is my judgement :-)

Two persons should checkout, build and run ITs. If the testMVCProject is the only failing test on all machines, the person who wrote it should have a quick look.

If we can't fix it fast, we release it like it is.

The migration of the internal types we do in a 1.2.1-Release next week or so.

- Lars


May 25, 2010 at 8:05 AM

I'm currently looking into the failing tests.


I've added necessary paths in my env var and if everything works fine in my local machine, will do the same on the ci server.



May 25, 2010 at 11:41 AM



There are no more failing test.


I've already added the custom-lifecycle-maven-plugin in the project group but unfortunately I can't delete the maven-deploy-plugin (http://pastie.org/975885)


I've already installed squirrel in the CI. After successful deletion of this in the db, I can start with the release of  NPanday-1.2-test.



May 25, 2010 at 1:44 PM

Thanks guys - I'm windows-less for the next couple of weeks so I'll have to leave it with you and CI to do the testing :)

May 26, 2010 at 1:27 AM

Liit ancountered some FK constraints error in the database in the CI while deleting the deploy plugin from the project group. I'll send an update once I've fixed this problem so the release can already be started. Thanks!

May 26, 2010 at 1:55 AM
On Tue, May 25, 2010 at 9:27 PM, [email removed] wrote:

> Liit ancountered some FK constraints error in the database in the CI while
> deleting the deploy plugin from the project group. I'll send an update once
> I've fixed this problem so the release can already be started. Thanks!

Has that been reported as a bug in Continuum? I've seen it too, but
have not yet figured out how to reproduce it.

A coworker had a theory that it happens when the parent gets deleted
before one or more children.

May 26, 2010 at 2:17 AM

I don't think it's filed yet in the community, I'll file it there now :) The error was in the ProjectDependency btw, I think there were some projects that are still referencing the deploy plugin that's why the error occurred but I'm still verifying this to make sure.

May 26, 2010 at 11:50 AM

I excluded the 3rd party artifacts in npanday-installer\pom.xml and dotnet-repository-builder\pom.xml coz build will fail for NPanday Windows Installer (it is unable to download from any repository since it was already removed from the 3rd party repo).

After getting a successful build for all the projects under NPanday Project Group, I proceed with the release and follow the steps found here:


But I didn't get a successful release prepare because I got an error in the 'generate-reactor-projects' phase (error: http://pastie.org/977789)

I already tried manually installing the said artifact but still get the same error during release prepare.

Any thoughts/suggestions?


May 26, 2010 at 1:20 PM
Edited May 26, 2010 at 1:21 PM

The artifact wasn't resolved because the artifact installed in the local repository of the ci server had an incorrect classifier. I already installed the artifact with the correct classifier so you should be able to proceed with the release now..

May 26, 2010 at 3:09 PM

Did something else go wrong? Aren't these in the GAC? Liit's change should be fine, but something else might be wrong as indicated by Deng's reply.

Perhaps we prematurely moved to relying on NPanday 1.2's GAC logic, but the current build uses 1.1 still to build itself.


May 27, 2010 at 2:53 AM

I think we're encountering this bug in the CI server:


The NPanday CI is still using Maestro 2.3.1 which bundles Continuum 1.3.5. The above bug is fixed in Continuum 1.3.6. I suggest we release NPanday 1.2 from the command-line for now, then upgrade the CI server to Maestro 2.3.2 which has Continuum 1.3.6 in it. What do others think?


May 27, 2010 at 2:56 AM
Yup I think that does make sense, how about we release from the command line for the mean time and then upgrade to 2.3.2
May 27, 2010 at 3:22 AM

I agree on upgrading the build server to Maestro 2.3.2.


I will just release NPanday 1.2 from the command line.


I'll keep you guys posted.


Thanks! :)

May 27, 2010 at 9:21 AM
When the release is good, should we bump to 1.2.1? or create a 1.2 branch and dedicate the trunk to 2.0? I'm pretty sure we will have to do some bug fixes before we release 2.0 :-)
May 29, 2010 at 11:25 PM

Liit, whats the status??

May 31, 2010 at 11:48 AM


I have tried releasing through the command line but was not able to release successfully.  I was able to supply the release parameters (version, scm tag, next development version) but got stucked up during the building part and got this error:


I've checked on my local repository and the missing artifacts are already installed.

I will try releasing tonight using Continuum 1.3.6 and will keep you guys updated.

Comments/Suggestions are always highly appreciated.

Thanks again for your patience and support.

May 31, 2010 at 3:15 PM

If it doesn't work through the command line it won't work through Continuum. I wouldn't suggest changing things just to keep trying it without understanding the root problem first.

First of all, it is looking for 1.2-SNAPSHOT. I assume this is after the POMs have been rewritten - you should check why the repository builder is not attempting to look for 1.2.

Further, that error is related to the removal of the deploy plugin. It wasn't working at all initially, but I tried to fix that by adding the build-helper plugin into the NPanday.Model.Pom pom.xml already. You might want to double check the DLL is in your local repository after the Model.Pom module was built.


Jun 1, 2010 at 2:27 AM
Edited Jun 1, 2010 at 3:08 AM

You need to activate the profile when you run 'mvn release:prepare' so that the dotnet-repository builder, npanday-repository builder and the npanday installer projects also get built and their versions updated to the release version. The -Pnpanday-release argument configured for the maven-release-plugin in the POM is only effective in the preparation goals. That's the reason why the versions in the repository builder was not updated to 1.2.

Jun 1, 2010 at 2:55 AM

BTW, I think there's another potential issue when releasing from the NPanday CI. In the npanday-release profile in the POM, the GPG plugin is configured. Whose key will be used to sign the artifacts when the release is done in the CI?

Jun 1, 2010 at 3:06 AM

Ok, that's my bad - I listed that as something to check earlier :)

Perhaps we should take those modules back out of the profile.

Jun 1, 2010 at 3:11 AM

It should be fine to set them there I would think, as long as it is documented (maybe in the release process doc) so it wouldn't be missed next time? :)

Jun 1, 2010 at 3:17 AM

but that won't work from Continuum?

Jun 1, 2010 at 3:24 AM

Yeah.. you're right, it wouldn't work from Continuum. And there's also the issue with the artifact signing that I've mentioned above if releasing from the CI.

Jun 2, 2010 at 1:17 AM


I was able to do a successful release:prepare and the tag can be found here: https://npanday.svn.codeplex.com/svn/releases/npanday-project-1.2-RC1/

But during release:perform, I encountered this error -> http://pastie.org/987196

I'll check on the configs further coz maybe there's still some modules referencing the npanday-deploy-plugin which was already removed.


Jun 2, 2010 at 3:13 AM
Edited Jun 2, 2010 at 4:53 AM

The build is using NPanday compiler plugin version 1.1 (see <pluginManagement> in ../dotnet/pom.xml) where the NPanday deploy plugin is the one bound to the deploy phase in the lifecycle mapping for projects of type "library" (see https://npanday.svn.codeplex.com/svn/releases/npanday-project-1.1/plugins/maven-compile-plugin/src/main/resources/META-INF/plexus/components.xml for reference). I don't know why the build still use the NPanday deploy plugin that was bound to the deploy phase even if the maven-deploy-plugin version is configured in the POM.

In the dotnet/pom.xml, there is a note that version 1.1 of the compiler & resgen plugins were used because of MNG-1911. Brett commented in the issue that MNG-1911 is fixed in Maven 2.2.1, so I guess it would be alright to upgrade the compiler plugin to 1.2-SNAPSHOT as long as Maven 2.2.1 version is used for the release?

Jun 2, 2010 at 3:22 AM

it's not actually fixed...

Jun 2, 2010 at 4:36 AM

Sorry, I misread your comment on the issue. It was just the patch that works on Maven 2.2.1.