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.