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

1.1 Motivations for Maven

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

1.2 Getting Started with Maven

1.3 pom.xml

The Maven build file is pom.xml. The POM for our simple project is

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>edu.odu.cs</groupId>           ➀
  <artifactId>codeAnnotation</artifactId> ➀
  <packaging>jar</packaging>              ➁
  <version>1.0-SNAPSHOT</version>
  <name>codeAnnotation</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

• Yep, more XML.
• ➀ Here you see the project identification we indicated.
• ➁ Set by the chosen archetypeArtifactId

2 Maven Innovations: archetypes

What you didn’t see in the pom.xml were the targets/tasks that would be used.

• Like ant, Maven is based on task dependencies.
• But the tasks are hidden in a remote file that describes the archetype
  • The directory structures, targets, and tasks for building a particular kind of project.
• Individual projects cannot change the archetype
  • Can _configure _ it by setting values of archetype-defined parameters.
  • But cannot do things like add/remove tasks.

2.1 Archetypes Enforce Someone’s Idea of Best Practices

Archetypes can be supplied by

2.2 Extending Maven for an Individual Project

Maven is usually extended by adding plugins

• Each plugin is a collection of related MOJOs, a Maven plain Old Java Object
  • Each MOJO provides a specific function
  • which can be bound to a specific goal of the life cycle for our selected project archetype
• Plugins cannot add/remove/reorder the task dependency tree of an archetype
  • But they can add actions to be performed during some of those tasks.

2.2.1 Plugin Example - JFlex

This project adds a stage before compilation to generate some of the source code that then needs to be compiled.

2.2.2 Plugin Example - Ant

3 Maven Innovations: 3rd Party Libraries

3.1 Dependencies

Picking up with the example we used earlier.

• Examine the pom.xml file and look for the dependencies section.

  You should see something like

    <dependencies>
  	<dependency>
  	  <groupId>junit</groupId>
  	  <artifactId>junit</artifactId>
  	  <version>3.8.1</version>
  	  <scope>test</scope>
  	</dependency>
    </dependencies>
  

• This indicates that our project requires the junit package.

  • But it’s an old version. JUnit changed a lot in version 4 (and even more in version 5).

3.1.1 Updating the Dependency

• Change the version number to

    <dependencies>
  	<groupId>junit</groupId>
  	<artifactId>junit</artifactId>
  	<version>4.10</version>
  	<scope>test</scope>
    </dependencies>
  
  

  • Could also say [4.10,] to get versions 4.10 or greater

• Try mvn package again.

3.1.2 Fetching Dependencies

• Maven does a transitive search over the dependencies for a project

  • Tries to find a mutually compatible set of versions
    • Helps if you give it some flexibility

• Maven then downloads the required libraries automatically

  • Downloaded libraries are cached (e.g., ~/.m2)

3.1.3 Version Ranges

• Version ranges can be specified as [low,high]

  • [ and ] are inclusive. Use ( and ) for exclusive
  • If low or high are omitted, taken as \( \pm\infty \).

• Examples

  • [4.0,4.10] inclusive range
  • [4.10,) 4.10 or anything more recent
  • [4.10] 4.10 and nothing else
  • 4.10 with no brackets means “any version, but prefer 4.10”

3.1.4 Maven Repositories

3.1.5 Transitive Dependencies

How does Maven know whether junit itself depends on other libraries?

• Near the top of the junit 4.10 page, click to “View” the POM file:

  Near the bottom, you will see

    <dependencies>
  	<groupId>org.hamcrest</groupId>
  	<artifactId>hamcrest-core</artifactId>
  	<version>1.3</version>
  	<scope>compile</scope>
    </dependencies>
  
  

• This is the same kind of info that we put into our own pom.xml file

  • And is, presumably, taken from the pom.xml that the JUnit team used to maintain their builds.
  • Publishing the dependency information along with the libraries leads to an accumulated base of information on library dependencies.

3.2 This was a Game Changer!

The combination of

• easy importation of libraries into a build, and
• large, well-known repositories of available libraries

was a tremendous advance.

Probably the major factor in attracting Java developers to start working with Maven.

3.2.1 “Imitation is the sincerest form of flattery”

(Oscar Wilde)

• Before long, Ant users were anxious for this same capability.
  • Ivy is an Ant plugin that adds this to Ant
    • even searches the same Maven repositories for libraries
• Gradle would offer the same ability
• Other programming languages have sought to provide the same in the form of
  • language-specific build managers
  • language-specific repositories