Maven is a promising application development lifecycle management framework coming from Apache's armory of open source tools. Maven was originally developed as a framework to manage and mitigate the complexities of building the Jakarta Turbine project and soon became a core entity of the Apache Software Foundation project.

Without a uniform application development lifecycle management framework, different development teams would create their own build frameworks with varying flavors and complexity and this tendency would only proliferate as more and more new projects get developed. The creation of different build approaches for different projects would lead to build system disparity lacking reuse of build logic that would impede developers in moving easily between the projects because every time a developer starts working on a different project, the developer would spend too much time understanding the prevalent build system, its configuration, and usage instead of focusing on the core components.

This type of perplexity was particularly felt in the open source community. There was a definite need for a standardized project development lifecycle management system. The advent of Maven as part of the Jakarta Turbine project was the perfect remedy for the old malady.

As the name suggests, Maven is a connoisseur of build process. It encapsulates years of project development lifecycle management knowledge and tremendously simplifies the build process by extensively reusing build logic and eliminating most of the grunt work typical of the usual application development process. Ever since, Maven has been extensively used in the open source community for building projects and in the process was enhanced and extended to bring it to its current mature state. Maven, currently at version 2, has become the de facto build system in many open source initiatives and is being adopted by many software development organizations.

Development teams usually would have a plethora of challenges and concerns during typical application project development. The following are a few such examples:

• What should the project directory structure be?
• How should source, test source, libraries, configuration, documentation, and report directories be laid out?
• Where should the dependent library Jars be downloaded from?
• What versions of library Jars should be used for the project?
• What about the other Jars that the project library Jars depend on internally? Where should such Jars be downloaded from? What versions of such Jars should be used? Is there an easy way to know the compatible versions?
• What is the best way to resolve dependent library Jar version conflicts?
• Where should the library Jars be located?
• How should the project keep up with the latest versions of dependent Jar files?
• How should the compile time, runtime, and testing time classpath libraries be separated?
• How should compile time, runtime, and testing time resources be separated?
• Is there an easy way to execute all test cases during the build process and immediately evaluate percentage test coverage?
• Is there an easy way to test code quality during the build process?
• Is there a way to integrate code profiling during the build process?
• Is there a way to run integration tests during the build process? How can continuous integration be achieved by developing custom build scripts?
• How should the build scripts be designed for different project building tasks?
• Where should build scripts be located in the overall project directory structure?
• Should there be a dedicated resource to maintain the build scripts while the project is being developed?
• How can consistent company-wide Jar libraries be maintained?
• Should new team members learn the custom build process?
• Should each project have its own inconsistent and typically non-standard build process?

The key benefit of this approach is that developers will follow one consistent build lifecycle management process without having to reinvent such processes time and again. Ultimately this will make developers to become more productive, agile, disciplined, and focused on the work at hand rather than spending time and effort doing grunt work understanding, developing, and configuring yet another non-standard build system.

Standard Conventions Used by Maven
Maven goes by the notion of "convention over configuration." Some of the common concerns when building a project are project directory structure, directory naming conventions, and the build output. For example, the directory structure of a Web application project will be slightly different from that of an EJB application project. Similarly the output of a Web application project is typically a WAR file while that of an EJB application is a JAR file. However, for a specific project type, the typical requirements in terms of directory layout and naming conventions are almost the same. Without a unified framework such as Maven, developers would typically spend time configuring such nitty-gritty details as setting up directories for source, resources, test case source, testing time resources, classes, and project dependencies. Moreover, developers will have to spend a good chunk of time creating build scripts such as ANT scripts to execute build tasks according to the project layout. This entire endeavor ends up being chaotic and in a large-scale project it can lead to a maintenance nightmare demanding dedicated resources just to focus on such build aspects.

Maven inculcates three main conventions to address common concerns:

1.  Projects of the same project type will have one common standard project directory structure: At project creation, Maven uses a standard project directory layout for source files, resources, test case source files, test resources, configuration files, output files, reports, and documentation. In almost all cases, this standard project directory layout is sufficient to carry out development tasks. However, a custom directory structure can also be configured by overriding Maven's defaults. This override is not generally recommended unless there's a compelling reason and will deviate from Maven's best practice propositions.

2.  Every project results in one primary artifact of specific type: Every project in Maven will result in one primary output file known as an artifact. For example, a Maven project containing a mathematical utility API will yield a JAR file containing compiled utility classes. The output JAR file is the resulting artifact of that project. Some other common artifact types are WAR, EAR, and RAR. Each artifact in Maven is uniquely designated by three Maven coordinates; artifact Id is the actual name of the artifact, group Id is the name of the group the artifact belongs to and the artifact version. This convention helps tremendously while resolving dependencies because every dependency in Maven is an artifact and so every dependency can be uniquely identified. This convention enables developers to think in terms of modularization at the code base level so that each project module yields one specific artifact specializing in one area of concern. This type of modularization encourages maximum reusability with different projects can now depend on only one functionally specialized and distinct artifact without having to include multiple disparate artifacts that may contain pieces of the required functionality.

3.  Use of standard naming conventions: Maven uses standard names for project directories and output files. For example, Maven creates a standard 'projectDirectory/src/main/java' directory for all Java source files and 'projectDirectory/src/test/java' directory for all Java test case source files. Similarly, while creating a project artifact, Maven follows a standard naming convention such as 'artifactName-version.' An artifact version is typically represented in a standard format of 'MMM.mmm.bbb-qqqqqqq-nn' where 'MMM' is the major version number, 'mmm' is the minor version number, 'bbb' is the bug fix number,' 'qqqqqqq' is an optional qualifier, and 'nn' is an optional build number. Such naming conventions offer immediate clarity and in the case of artifacts, enable cohesive and consistent organization of dependencies using their respective artifact coordinates.