Maven Overview
Maven provides a comprehensive approach to managing software projects. From compilation, to distribution, to documentation, to team collaboration, Maven provides the necessary abstractions that encourage reuse and take much of the work out of project builds.
What is Maven?
Maven is a project management framework, but this doesn’t tell you much about Maven. It’s the most obvious three-word definition of Maven the authors could come up with, but the term project management framework is a meaningless abstraction that doesn’t do justice to the richness and complexity of Maven. Too often technologists rely on abstract phrases to capture complex topics in three or four words, and with repetition phrases such as and start to lose concrete meaning.
When someone wants to know what Maven is, they expect a short, sound-bite answer.“Well, it is a build tool or a scripting framework.”Maven is more than three boring, uninspiring words.It is a combination of ideas, standards, and software, and it is impossible to distill the definition of Maven to simply digested sound-bites.Revolutionary ideas are often difficult to convey with words.If you are interested in a fuller, richer definition of Maven read this introduction; it will prime you for the concepts that are to follow.If you are reading this introduction just to find something to tell your manager1, you can stop reading now and skip to Chapter 2.
So, what exactly is Maven?Maven encompasses a set of build standards, an artifact repository model, and a software engine that manages and describes projects.It defines a standard life cycle for building, testing, and deploying project artifacts. It provides a framework that enables easy reuse of common build logic for all projects following Maven’s standards.The Maven project at the Apache Software Foundation is an open source community which produces software tools that understand a common declarative Project Object Model (POM). Thisbook focuses on the core tool produced by theMavenproject, Maven 2, a framework that greatly simplifies the process of managing a software project.
You may have been expecting a more straightforward answer. Perhaps you picked up this book because someone told you that Maven is a build tool.Don’t worry, Maven can be the build tool you need, and many developers who have approached Maven as another build tool have come away with a finely tuned build system.While you are free to use Maven as “just another build tool”, to view it in such limited terms is akin to saying that a web browser is nothing more than a tool that reads hypertext.
Maven, and the technologies related to the Maven project, are beginning to have a transformativeeffect on the Java community.
In addition to solving straightforward, first-order problems such as simplifyingbuilds, documentation, distribution, and the deployment process, Maven also brings with it some compelling second-order benefits.
As more and more projects and products adopt Maven as a foundation for project management, it becomes easier to understand the relationships between projects and to establish a system that navigates and reports on these relationships.Maven’s standard formats enable a sort of “Semantic Web” for programming projects.Maven’s standards and centralized repository model offer an easy-to-use naming system for projects.Using Maven has made it easier to add external dependencies and publish your own project components.
So, to answer the original question:Maven is many things to many people. It is a set of standards and an approach to project development, as much as it is a piece of software.Maven is a way of approaching a set of software as a collection of highly-interdependent components, which can be described in a common format.It is the next step in the evolution of how individuals and organizations collaborate to create software systems. Once you get up to speed on the fundamentals of Maven, you will wonder how you ever developed without it.
Maven’s Origins
Maven was borne of the practical desire to make several projects at the Apache Software Foundation (ASF) work in the same, predictable way. Prior to Maven, every project at the ASF had a different approach to compilation, distribution, and Web site generation. The ASF was effectively a series of isolated islands of innovation. While there were some common themes across the separate builds, each community was creating its own build systems and there was no reuse of build logic across projects. The build process for Tomcat was different than the build process for Struts, and the Turbine developers had a different site generation process than the Jakarta Commons developers.
This lack of a common approach to building software meant that every new project tended to copy and paste another project’s build system. Ultimately, this copy and paste approach to build reuse reached a critical tipping point at which the amount of work required to maintain the collection of build systems was distracting from the central task of developing high-quality software. In addition, for a project with a difficult build system, the barrier to entry was extremely high; projects such as Jakarta Taglibs had (and continue to have) a tough time attracting developer interest because it could take an hour to configure everything in just the right way. Instead of focusing on creating good component libraries or MVC frameworks, developers were building yet another build system.
Maven entered the scene by way of the Turbine project, and it immediately sparked interest as a sort of Rosetta Stone for software project management. Developers within the Turbine project could freely move between subcomponents, knowing clearly how they all worked just by understanding how one of the components worked. Once developers spent time learning how one project was built, they did not have to go through the process again when they moved on to the next project. Developers at the ASF stopped figuring out creative ways to compile, test, and package software, and instead, started focusing on component development.
The same standards extended to testing, generating documentation, generating metrics and reports, and deploying. If you followed the Maven Build Life Cycle, your project gained a build by default. Soon after the creation of Maven other projects, such as Jakarta Commons, the Codehaus community started to adopt Maven 1 as a foundation for project management.
Many people come to Maven familiar with Ant, so it’s a natural association, but Maven is an entirely different creature from Ant. Maven is not just a build tool, and not necessarily a replacement for Ant.
Whereas Ant provides a toolbox for scripting builds, Maven provides standards and a set of patterns in order to facilitate project management through reusable, common build strategies.
However, if your project currently relies on an existing Ant build script that must be maintained, existing Ant scripts (or Make files) can be complementary to Maven and used through Maven’s plugin architecture. Plugins allow developers to call existing Ant scripts and Make files and incorporate those existing functions into the Maven build life cycle.
What Does Maven Provide?
Maven provides a useful abstraction for building software in the same way an automobile provides an abstraction for driving. When you purchase a new car, the car provides a known interface; if you’ve learned how to drive a Jeep, you can easily drive a Camry. Maven takes a similar approach to software projects: if you can build one Maven project you can build them all, and if you can apply a testing plugin to one project, you can apply it to all projects. You describe your project using Maven’s model, and you gain access to expertise and best-practices of an entire industry.
Given the highly inter-dependent nature of projects in open source, Maven’s ability to standardize locations for source files, documentation, and output, to provide a common layout for project documentation, and to retrieve project dependencies from a shared storage area makes the building process much less time consuming, and much more transparent.
Maven provides you with:
- A comprehensive model for software projects
- Tools that interact with this declarative model
Maven provides a comprehensive model that can be applied to all software projects. The model uses a common project “language”, and the software tool (named Maven) is just a supporting element within this model. Projects and systems that use Maven’s standard, declarative build approach tend to be more transparent, more reusable, more maintainable, and easier to comprehend.
An individual Maven project’s structure and contents are declared in a Project Object Model (POM), which forms the basis of the entire Maven system. The key value to developers from Maven is that it takes a declarative approach rather than requiring developers to create the build process themselves, referred to as “building the build”. Maven allows developers to declare life-cycle goals and project dependencies that rely on Maven’s default structures and plugin capabilities, in order to perform the build. Much of the project management and build orchestration (compile, test, assemble, install) is effectively delegated to the POM and the appropriate plugins. Developers can build any given project without having to understand how the individual plugins work (scripts in the Ant world).
Organizations and projects that adopt Maven benefit from:
- Coherence – Maven allows organizations to standardize on a set of best practices. Because Maven projects adhere to a standard model they are less opaque. The definition of this term from the American Heritage dictionary captures the meaning perfectly: “Marked by an orderly, logical, and aesthetically consistent relation of parts.“
- Reusability – Maven is built upon a foundation of reuse. When you adopt Maven you are effectively reusing the best practices of an entire industry.
Agility – Maven lowers the barrier to reuse not only for build logic, but also for software components. Maven makes it is easier to create a component and then integrate it into a multi-project build. Developers can jump between different projects without the steep learning curve that accompanies custom, home-grown build systems. - Maintainability – Organizations that adopt Maven can stop “building the build”, and focus on building the application. Maven projects are more maintainable because they follow a common, publicly-defined model.
Without these advantages, it is improbable that multiple individuals can work productively together on a project. Without visibility it is unlikely one individual will know what another has accomplished and it is likely that useful code will not be reused.
When everyone is constantly searching to find all the different bits and pieces that make up a project, there is little chance anyone is going to comprehend the project as a whole. Further, when code is not reused it is very hard to create a maintainable system. As a result you end up with a lack of shared knowledge, along with a commensurate degree of frustration among team members. This is a natural effect when processes don’t work the same way for everyone.