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: Yeshim Deniz, Elizabeth White, Pat Romanski, Liz McMillan, 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

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)
Standard Directory Layout
Another tenet Maven follows to simplify project development is the use of standard directory layouts for project sources, additional project resources, and documentation (generally referred to as "project content"). Maven encourages a common arrangement for project content so engineering teams can quickly and predictably find any project-related items whenever Maven builds projects. This tenet dovetails with Maven's "convention over configuration" concept. So, while the location of the project content isn't critical to a project's success, it is critical that every member of that project team (both now and in the future) knows exactly where to look to find the project's content. Maven's standard directory structure ensures that developers can become familiar with a project tree and easily find project content simply by navigating that project's Maven structure.

Build Lifecycle
Recall earlier we said that while projects can have nearly infinite variability, Maven binds these potential inconsistencies and discrepancies in the well-defined structure of its build framework. The framework that Maven uses to accommodate project variations is defined as the build lifecycle. In Maven this frame-work consists of an ordered series of lifecycle "phases," where each phase can perform one or more actions (a k a "goals" in Maven-speak). The build lifecycle's phases use highly abstracted names such as compile, test, package, and deploy. While any number of goals (actions) can be performed during the test phase, the framework for the lifecycle itself remains well-defined and clearly articulated for any developer working on the project. During testing, for example, an engineer may need to run unit tests, create databases, deploy EAR files to an application server, and run coverage tools. With Maven, there are no restrictions as to the number or type of goals required; there is simply a convention (an embedded best practice) that defines how, where, and when these actions will be processed - specifically in the test phase, as it's defined in Maven's build lifecycle.

Visibility and Collaboration
Consider your own development environment, where everyone is constantly rooting around trying to figure out where all the different bits and pieces that make up a given project are located. This means there's very little opportunity for the team, or any individual engineer, to comprehend the project as a whole. While Maven's basic concepts of convention over configuration, model-driven declarative execution, standard directory layout, and build lifecycle all support build comprehensibility and maintainability, the next step in improving the software development lifecycle requires build visibility and reusability.

Without visibility, it's unlikely that an individual engineer will ever know what another engineer has contributed. As such, there's a good chance that useful code won't be leverageable - forcing teams to lose out on the network effects of code reusability. Even a well-maintained build can end up being a silo if there's no way to effectively share that project knowledge widely. As a result, Maven provides standard reports and a continuous integration server, Continuum, for the specific purpose of improving project visibility. Maven's reporting capabilities, when used in conjunction with Continuum, provide real-time metrics regarding not only the overall health of any Maven-built project, but also fine-grained details about code coverage, code quality, developer activity, and project issues.

Maven's goal of delivering project visibility, re-usability, maintainability, and comprehensibility takes it beyond the confines of being a build tool. It ensures that organizations and teams can leverage not only all project intelligence, but also the ongoing health assessments of their projects. Maven's real-time engineering framework supplements community-oriented best practices to measurably improve the predictably and velocity of software development and not just software builds.

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 (0)

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.