This project is read-only.

Tactical solutions necessary to build NPanday 0.9 Release

Dec 30, 2008 at 10:15 PM
While building NPanday 0.9 on Windows XP I encountered several problems not addressed by the README accompanying the release. I have attempted to document the various problems and the tactical solution I used to solve them.

Issue A:

Change the first mvn call in bootstrap-build.bat to be more explicit in identifying the install plugin. For whatever reason maven was having trouble finding the right install plugin, which the below fix resolved. I changed:

cmd /C mvn.bat 	install:install-file -Dfile=./thirdparty/ -
DpomFile=./thirdparty/ -DartifactId=XmlSchema -
Dversion=1.1 -Dpackaging=jar
cmd /C mvn.bat org.apache.maven.plugins:maven-install-plugin:install-file -
Dfile=./thirdparty/ -DpomFile=./thirdparty/ - -DartifactId=XmlSchema -Dversion=1.1 -Dpackaging=jar
Notice I didn't give a version number for the maven-install-plugin so the version will still be derived from information in the super pom.

Issue B:

Ensure maven is configured to be aware of the following external 3rd party maven repo. I configured my repo manager (Nexus) to include it, but you could add it directly to your .m2/settings.xml file if you prefer.

Issue C:

Ensure xsd.exe is in your path. For me this in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin To avoid conflicts with some other work I am doing, I am currently using a small batch script to enhance my PATH when working with maven. The contents are currently:

set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_07
set PATH="C:\Program Files\NUnit-Net-2.0 2.2.9\bin";"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727";"C:\Program
Files\Microsoft Visual Studio 8\SDK\v2.0\bin";%JAVA_HOME%\bin;%PATH

Issue D:

While running "bootstrap-build.bat -DMicrosoft" I encountered an exception complaining NPanday.VisualStudio:NPanday.VisualStudio:pom:0.9-SNAPSHOT could not be found. This exception occurred while building org.apache.maven.dotnet:dotnet-repository-builder:pom:0.9-SNAPSHOT. I expect this is a build order issue. To work around the problem I simply ran mvn install on all of the assemblies modules and then re-ran "bootstrap-build.bat -DMicrosoft".

prompt>cd npanday_0_9\assemblies
prompt>mvn install -DVisualStudio2005

Note: Make sure nunit-console is on your path before you do this.

Note: Make sure you set the VisualStudio2005 flag so the NPanday.VisualStudio.* modules will be included.

Jan 2, 2009 at 10:05 PM
Edited Jan 3, 2009 at 2:26 AM
I am now building from trunk, and have encountered the following additional issues.

Issue T1:

I tried to generate a site report for plugins\maven-vsinstaller-plugin and found the reports were configured to use an incorrect version of maven-plugin-plugin. This appears to be a simple bug introduced by a copy/replace accross the pom file(s).

The change needs to be made in plugins\pom.xml


change to:

Assuming it wouldn't introduce any clashes elsewhere, the version should really be provided higher up in the top level pom in pluginDependencyManagement.

Issue T2:

When I tried to install the VisualStudio plugin using:

prompt>mvn npanday.plugin:maven-vsinstaller-plugin:install
I discovered the .NET assemblies in the assemblies subdirectory needed to be digitally signed so the maven-vsinstaller-plugin can place them into the GAC.

Rather than specify the keyfile in assemblies/pom.xml in the configuration of the compiler I instead simply passed it on the command line using the keyfile property.

#Create keyfile with public/private key
prompt>cd C:\npandaycheckoutdir
prompt>sn -k MyKeyfile.snk

#Rebuild assemblies
prompt>cd assemblies
prompt>mvn clean
prompt>mvn install -DMicrosoft -DVisualStudio2005 -Dkeyfile=C:\npandaycheckoutdir\MyKeyfile.snk

#Reattempt VisualStudio plugin installation
prompt>cd \
prompt>mvn npanday.plugin:maven-vsinstaller-plugin:install

As I have implemented additional fixes below, I am now finding another problem with the maven-vsinstaller-plugin. For some reason it is encountering problems resolving NPanday.Plugins:NPanday.Plugin.Settings:pom:0.9-SNAPSHOT. To figure this out I am going to have to take a much harder look at how the maven-vsinstaller-plugin is working, likely running it in IntelliJ to help sort things out. Its getting late so I'm going to quit for now. Hopefully some other brave soul who already understands this code will get to it before I do. My personal email is jcarpenter621 remove this @

Issue T3:

Towards the bottom bootstrap-build.bat has an "Installing 3rd Party Assemblies in the Local Repo" section in which it runs a npanday specific install plugin. The group name should be changed from npanday.plugins to npanday.plugin.


cmd /C mvn.bat npanday.plugins:maven-install-plugin:install-file ...
cmd /C mvn.bat npanday.plugin:maven-install-plugin:install-file ...

Issue T4:

pom-dotnet.xml still has a reference to org.apache.maven.dotnet.plugins:maven-compile-plugin change this to npanday.plugin:maven-compile-plugin

Issue T5:

When the org.apache.maven.dotnet.plugins groupId was renamed to npanday.plugin several files were not updated as they should have been. This includes the plexus files in the maven-compile-plugin and maven-aspx-plugin modules.

While looking around I also noticed these plexus files don't reflect the change of the NPanday.Plugins groupId to it's lower case singular form npanday.plugin.

To resolve these problems edit the following two files and replace "org.apache.maven.dotnet.plugins:" and "NPanday.Plugins:" with "npanday.plugin:"


If you search all files in the project for org.apache.maven.dotnet.plugins you will find a few more usages in documentation, etc. which don't appear to affect the build. If I had commit access I might just clean all this up and commit them back. Since I don't, I'll leave this as an exercise for someone who does. Prior to locking things down one should ensure the groupId and artifactId case and plural/singular forms match the desired conventions. Prior to checking in the changes, it is critical you destroy your local repo caches and rerun the bootstrap from scratch. Failure to do this ends up with old versions of the same build version disguising the problems.

Issue T6:

Due to the crude way bootstrap-build.bat processes it's command line arguments, it is critical that -DMicrosoft be the first option.

The following example syntax should work.

prompt>bootstrap-build.bat -DMicrosoft -DVisualStudio2005  -Dkeyfile=C:\npandaycheckoutdir\MyKeyfile.snk
Jan 6, 2009 at 5:30 AM
These errors are caused by the  re branding it gave us the following things to work on:
              1. The wrong folder structures in the source code
                       - this would the null pointer exceptions on the plugins because the plugins are not located.
               2. Some pom files still had incorrect versions in them
                       - this would cause the wrong artifacts to be invoked.

After working on these things we will post a release candidate and follow the release guidelines. We hope a lot of people will be able to join in and test the RC and vote as well.