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: Liz McMillan, Carmen Gonzalez, Mehdi Daoudi, Pat Romanski, Elizabeth White

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

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 framework 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 (1)

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.