1. Why Maven?

Another Apache project, Maven came well after Ant had come to dominate the Java open source landscape.

• Initially seen as a competitor or replacement for Ant

• Maven addresses both
  • build management (as does Ant)
  • and configuration management (which Ant does not)
    • Later, we’ll talk about Ivy, which adds configuration mgmt to Ant

Motivations for Maven

Grew out of an observation that many supposedly cooperative, related Apache projects had inconsistent and incompatible ant build structures.

Stated goals are

• Making the build process easy

• Providing a uniform build system

• Providing quality project information

• Providing guidelines for best practices development

• Allowing transparent migration to new features

Uniform Build System

• Maven supports archetype projects that standardize
  • directory structure
    • Source code kept in separate directory tree from both intermediate and final build products
    • Tests occupy separate subtrees of the source and product trees
  • “Life Cycle”
    • Really, a presumptuous name on their part for a build process
    • A sequence of goals

• Archetypes can be obtained from the Maven project or tailored for an organization.

Providing quality project information

• Provides easy access to report tools

• Aids in building & maintaining project web sites (e.g.)

Providing guidelines for best practices development

• Directory structures (already discussed)

• Unit testing

• Encourage familiarity with approved archetypes

2. Maven as a Build Manager

Perhaps the best way to illustrate this is to follow the steps in Maven in 5 Minutes

• Start with the command

  mvn archetype:generate -DgroupId=edu.odu.cs \
    -DartifactId=codeAnnotation \
    -DarchetypeArtifactId=maven-archetype-quickstart \
    -DinteractiveMode=false
  

  • Lots of libraries (mainly comprising the latest version of Maven system itself) will be downloaded into your \string~/.m2 directory.
  • A directory, codeAnnotation, will be created.
• cd into the new directory and explore
  • src directory structure
  • pom.xml is the build file for this project

Building with the Sample Source

• Run mvn package

  • Sample source code is compiled
  • Sample unit test is run and executed.
  • A jar file is created with the sample source code

• Explore the target directory to see what has been placed there

OK, that was fun…

Let’s try this with some real source code.

• Delete the target directory (or run mvn clean)

• Replace the contents of src/main/java and src/test/java by the corresponding contents from my code Annotation project.
  • Also, copy src/main/jflex while we’re at it, though we won’t use this right away.

• Try mvn package again.

What Went Wrong?

• A glance at the code with the error messages won’t show anything obvious.
  • But I happen to know that Maven defaults to running the Java compiler in Java 5 compatibility mode
  • This code uses Java 7 features

• Edit the pom.xml file and, just above the <dependencies> section, add <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.7</maven.compiler.source> <maven.compiler.target>1.7</maven.compiler.target> </properties>

• Then try mvn package again

That was a little better

• The main source code compiled successfully.

• The error was in the compilation of the unit tests

  • The first error message says

    [ERROR] /home/.../codeAnnotation/src/test/java/edu/odu/cs/codeAnnotation/TestC2HOptions.java:[3,23] package org.junit does not exist
    

• Looks to be a problem with the JUnit library

• In the original project, I was keeping a copy of junit4.jar in the project directory.
  • A clumsy solution
  • Which we’ll solve when we take up configuration management.