CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Aater Suleman, Nate Vickery, PagerDuty Blog, XebiaLabs Blog, Mehdi Daoudi

Related Topics: Apache Web Server Journal, Continuous Integration

Apache Web Server: Article

Maven: A Different Way of Looking at Software Development

A real-time engineering framework

Software development is typically carried out in an opaque environment where progress can be slow and (too often) the resulting build processes lack visibility, transparency, and collaboration. The Apache Software Foundation's Maven project approaches the problem of building software by providing the technical underpinnings for a set of development methods that enable engineers and other stakeholders in a project to optimize build reliability, accelerate build velocity, and capture and share build knowledge. Maven differs from current script-based approaches to building software by first defining, standardizing, and then publishing the build process as a logically organized structured lifecycle. Having evolved from the Open Source development world of distributed, asynchronous, iterative, and highly component-based engineering, Maven's technology helps development teams effectively cooperate to create and deliver successful software projects consistently.

While people new to Maven tend to think of it as strictly a tool for builds (akin to Ant), Maven actually offers a set of tools, including a Project Object Model (POM), user-defined plug-ins, and functionally rooted best practices, whose goal is to measurably improve software development processes as a whole, rather than simply enable builds to compile.

But while there's definitely a "non-technical" element to developing software with Maven, its strong use of patterns and emphasis on community-oriented practices, the key to building with Maven comes from how its tooling technology actually enables and reinforces development best practices across a team. As anyone who has ever been part of a successful project knows, teams must creatively combine technical and non-technical elements to deliver quality projects. Maven's goal, in terms of its tooling, is to provide a solid and cohesive technical framework that can mitigate some of the human factors that hinder software development (e.g., one developer's code contribution breaking the build, non-standard locations for relevant cross- related project resources, and the inability to integrate new tools into the build process). Moreover, once engineers are relieved of the more mundane, time-consuming aspects of the build process, they can get on with the important work of creating value at the application level.

So let's take a closer look at the Maven project and explore how, when combined with good internal build procedures, its use can im-prove overall software development processes:

  • Apache Maven 2.0, the foundational POM-based build engine for Java projects
  • Apache Continuum 1.0, the Continuous Integration server fully integrated with Maven
  • Plug-ins, the standard way to work in Maven and extend its functionality
  • Maven SCM, the abstraction layer for SCMs in Maven's plug-ins and in Continuum, which supports CVS and SVN, as well as Perforce, Starteam, and ClearCase
  • Maven Wagon, the abstraction layer for general transport, heavily used in Maven and the Maven-Ant tasks library for moving artifacts between repositories
  • Doxia, the content generation library used to generate project sites and create build reports
  • Surefire, the abstraction layer for testing frameworks that support JUnit and general scripting (TestNG support is in development)
  • Archetypes, a rapid project prototyping tool that quickly sets up a template Maven project
Typically, developers who come to Maven are already familiar with Ant, so there's a natural association made between the two projects. Ant is a script-based toolbox, and an excellent one at that. However, Maven isn't simply a build tool and, as such, it's not a replacement for Ant. Instead, Maven combines its POM, plug-ins, Continuum, and embedded build lifecycle phases (which can actually include Ant tasks) to offer engineers a software development infrastructure that delivers project visibility, re-usability, maintainability, and comprehensibility.

Originally Maven arose from a very practical need to make several Apache projects functionally build in the same way. Then, as now for most developers, being able to freely move between multiple projects meant that each developer needed to clearly know and understand how each of the individual projects worked. This meant that for every project a developer needed to build, he had to repeatedly decipher and learn not only how to build the project in question, but also become familiar with its related testing, documentation, reporting, and deployment practices. Since all of the original Apache projects shared a number of build characteristics (lifecycle phases), Maven was developed to harness these commonalities. Given that all software projects need to be built, tested, packaged, documented, and deployed at the most base level - Maven was created to logically organize this build model and then orchestrate the process. Since there are also a great number of sub-functions possible at each phase of the build, test, package, document, and deploy lifecycle, Maven's build model lets users use (and create) plug-ins to meet build-specific requirements. But, at the same time, Maven constrains the overall build process to a single recognizable and repeatable model, creating a build framework (versus a build tool) that saves developers from having to (re)learn unique project builds time and time again.

Use of Patterns
Maven's build pattern emphasis was heavily influenced by the Gang of Four's design patterns that in turn borrowed heavily from Christopher Alexander's work in the realm of architecture. According to Alexander, "...patterns help create a shared language for communicating insight and experience about problems and their solutions." Maven's goal is to define a build structure so that problems can be approached consistently in terms of a common framework. By providing a lingua franca build, Maven facilitates build comprehension based on the following underlying framework concepts of:

  • Convention over configuration
  • Model-driven declarative execution
  • Standard directory layout
  • Build lifecycle
Each of these concepts helps developers deal with their build infrastructure at a higher level of abstraction, allowing more effective and timely communication. Let's explore each of these concepts further.

Convention over Configuration
One of Maven's central tenets is to provide logical default strategies for the most common build tasks, so that developers can avoid the mundane details. This notion is known as "convention over configuration" and has been popularized by the Ruby on Rails (ROR) community, specifically encouraged by ROR's creator David Heinemeier Hansson, who summarizes the notion as follows:

"Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility. The notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgment on one form of development over another. Well, Rails does, and I believe that's why it works.

With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.

"One characteristic of opinionated software is the notion of "convention over configuration." If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you're rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that which all add up to make a huge difference in daily use."

Hansson articulates very well what Maven strives to deliver: using standard conventions saves time, makes it easier to communicate to others, and allows engineering teams to get to the important work of creating value in their applications faster and with less effort. With Maven, developers won't spend a lot of time getting a development infrastructure functioning, instead they "slot in" various pieces where required, while Maven takes care of the tasks (goals) for that lifecycle phase. Maven handles all the building, document generation, or deployment work through its POM.

Model-Driven Declarative Execution
In Maven the POM is the central axis of work, since Maven is - by design - project-centric. Everything Maven needs to work with a given project is stored in the POM. Further, Maven uses the POM to execute and drive all of a project's build-re-lated functions. Maven's model-driven execution relies on the POM (an XML-based metadata description of a project), which is stored in a standard location with its related project.

In short, the POM contains every important piece of information about your project and is the "one-stop shop" for finding anything related that project. Below is a simple example POM that contains the key elements common to all POMs:

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Maven Quick Start Archetype</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>

The POM is typically stored in a file named pom.xml and sits at the top level of your project. The following are descriptions of the key elements in the POM above:

  • project - the top-level element in all Maven pom.xml files
  • modelVersion - indicates the version of the object model this POM is using (the model version itself changes infrequent-ly but it's mandatory to ensure stability if/when the Maven community deems a model change necessary)
  • groupId - indicates the unique identifier of the organization/group that created the project (groupId is one of the key iden-tifiers of a project and is typically based on the fully qualified organization domain name, e.g., org.apache.maven.plugins is the groupId for Maven's plug-ins)
  • artifactId - indicates the unique base name of the primary artifact being generated by this project, typically a JAR file (a typical artifact would have the form <artifactId>-<version>.<extension>, e.g., myapp-1.0.jar)
  • packaging - indicates the package type to be used by this artifact (e.g., JAR, WAR, EAR, etc. and describes that the artifact produced is JAR, WAR, or EAR, but can also indicate the specific lifecycle to be used)
  • version - indicates the version of the artifact generated by the project.
  • name - indicates the display name used for the project (used in Maven-generated documentation)
  • url - indicates where the project's site can be found (used in Maven-generated documentation)
  • description - provides a basic description of the project (used in Maven-generated documentation)

More Stories By Jason Van Zyl

Jason is the founder and CTO of Sonatype, the Maven company, and founder of the Apache Maven project, the Plexus IoC framework, and the Apache Velocity project. Jason currently serves on the Apache Maven Project Management Committee. He has been involved with the Apache Software Foundation (ASF) for seven years, helped to found Codehaus, a well-respected incubation facility for open source community projects, and is a frequent speaker at many major software conferences, including JavaOne, EclipseCon, EmergingTech, and ApacheCon.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
JDJ News Desk 05/19/06 01:30:39 PM EDT

Software development is typically carried out in an opaque environment where progress can be slow and (too often) the resulting build processes lack visibility, transparency, and collaboration. The Apache Software Foundation's Maven project approaches the problem of building software by providing the technical underpinnings for a set of development methods that enable engineers and other stakeholders in a project to optimize build reliability, accelerate build velocity, and capture and share build knowledge. Maven differs from current script-based approaches to building software by first defining, standardizing, and then publishing the build process as a logically organized structured lifecycle. Having evolved from the Open Source development world of distributed, asynchronous, iterative, and highly component-based engineering, Maven's technology helps development teams effectively cooperate to create and deliver successful software projects consistently.