About the POM file

First, we need to understand what the pom.xml file is. This is the sole descriptor used by Maven to build an entire project. In some respects, it is similar to the .sln and .csproj (or .vbproj) files, however Maven uses a different approach - while these are 'scripts', the POM is 'declarative', indicating where parts of the project are located, and which Maven plugins are used to build the project, utilizing that project information. By being declarative in this fashion, many plugins can operate on the same information without having to reconfigure each specifically.

Let's look at POM for the solution first:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
         xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>MyCompany.NPandayTestQS</groupId>
  <artifactId>NPandayTestQS-parent</artifactId>
  <packaging>pom</packaging>
  <name>MyCompany.NPandayTestQS : NPandayTestQS-parent</name>
  <version>1.0-SNAPSHOT</version>
  <modules>
    <module>NPandayTestQS</module>
  </modules>
</project>

You will notice a few important elements here. First, there is the Group ID which is the value that you entered into the previous dialog. There is also an Artifact ID that is the name of the solution with 'parent' appended. Further down, there is a Version that is set to the default of 1.0-SNAPSHOT. These 3 elements constitute the project co-ordinate, which is a unique identifier across all projects you can access to this particular project. This is the reason that the solution appends -parent to the end, to distinguish it from the child project with the same name.

Within the group/artifact ID combination, each project is then versioned to distinguish between different releases. The default is 1.0-SNAPSHOT, which means "in development towards the 1.0 release". Maven places special significance on the SNAPSHOT addition to a version, which means that the project is changing. When a version is set to a concrete one such as 1.0, Maven considers it to always remain the same and changes to go under a new version (such as 1.1-SNAPSHOT).

We will later use these co-ordinates to locate and utilize dependencies on other projects from within our own project, even if we don't have a copy locally.

We also see the Modules section that shows which subproject exist. This contains a reference to the class library's project directory - so let's now look at the POM for that:

<?xml version="1.0" encoding="utf-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
         xmlns="http://maven.apache.org/POM/4.0.0">
  <parent>
    <artifactId>NPandayTestQS-parent</artifactId>
    <groupId>MyCompany.NPandayTestQS</groupId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>..\pom.xml</relativePath>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>NPandayTestQS</artifactId>
  <packaging>library</packaging>
  <name>MyCompany.NPandayTestQS : NPandayTestQS</name>
  <build>
    <sourceDirectory>./</sourceDirectory>
    <plugins>
      <plugin>
        <groupId>npanday.plugin</groupId>
        <artifactId>maven-compile-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <frameworkVersion>2.0.50727</frameworkVersion>
          <includeSources>
            <includeSource>Class1.cs</includeSource>
            <includeSource>Properties\AssemblyInfo.cs</includeSource>
          </includeSources>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

This project starts with the Parent definition, which points back to the project for the solution. This is used to inherit any shared settings among subprojects (though by default, there is nothing saved in the parent POM that will be shared).

Next we have the artifact ID for this project, which uses the library name. The group ID and version can be omitted, since by default they will use the same one as the parent project.

In this project, we have altered the Packaging element to be of type library. While the parent was a pom, indicating it didn't build anything additional, this type indicates that Maven and NPanday should include all the standard build steps for a .NET class library.

Along with this we now have a Build section. This contains two further elements - first, the source directory, that says the Visual Studio convention of storing source files in the project directory (and subdirectories) will be followed. Next is the Plugins section, which is where Maven is told to use NPanday to compile, and what framework and source code to use. For other project types, additional plugins may be added (see the Plugins Reference for more available plugins).

While it is not necessary to be able to create these POM files to be able to use NPanday, understanding how they work, and in particular the Maven co-ordinate system, will help to understand what NPanday is doing "behind the scenes" when you use some of its other functionality.

The Build Lifecycle

Maven uses the POM to drive builds that a constructed as patterns. No matter what type of project you are building it can be shaped to Maven's build lifecycle, which is a sequence of phases always run in the same order, and for which a given phase can be sure that the previous phases have always executed as part of this build.

There are quite a number of phases that Maven plugins can participate, and that you can run from the mvn command, but the Visual Studio Add-in exposes the primary ones:

• compile - compile source code into binary output
• test - run unit tests (such as NUnit) against the code to verify that the package will work
• install - produce the package and install it into Maven's local repository.

What this means is that if you run mvn install, you will actually run compile, then test, then install (and the intermediate steps). Maven views testing as important, so this structure ensures that you run any unit tests you have before using the final DLL, for example. Running the install phase is the most common one used when building a project with Maven.

The installation phase is different to the traditional meaning of installing software. Maven maintains a local repository on the current machine (by default in %HOMEDRIVE%%HOMEPATH%\.m2\repository) where all build output is stored. This common storage allows sharing between different projects on the same machine when they express a dependency on another project. You have already encountered this when installing NPanday, as Maven uses the local repository to house it's own functionality as well.

We'll also learn later that Maven utilizes remote repositories to obtain dependencies from other sources, and to publish build output for sharing with other users. In this case, the local repository acts as a local intermediatary and cache between Maven and the remote repositories.

In addition to the above phase, there is the Clean option, which uses a different 'lifecycle' for cleaning up any build output such as the target, Bin and Obj directories.