uilding enterprise Java applications is a challenging process in which you build, package, and deploy multiple components to a variety of environments. And these components will frequently depend on one another and on third-party libraries and frameworks. Furthermore, you must also manage static resources, configuration files, and deployment descriptors, as well as produce packages that are compliant with J2EE specifications. You may also want all of this tested and plugged into a continuous integration build system. Every enterprise application built will address these issues to some extent, and most will do so differently.
Maven tackles this challenge head-on by abstracting tasks and processes commonly performed across applications. By following some recommended practices, and by supplying some descriptive information about your project, you can enable Maven to take care of many of the activities involved in building your application. As an example, one best practice that Maven recommends is a common directory structure for your project. If you follow this structure then Maven can automatically package your application for you. Of course you can deviate from the layout recommended by Maven but you will then have to provide Maven with additional configuration information.
Central to Maven is the concept of a Project Object Model (POM). The POM consists of meta-data describing the project to be built. This provides a standard way of describing important aspects of your project such as versioning, dependencies, resources, and much more. This allows you, for example, to list your project's dependencies in an XML file and have Maven take care of downloading these dependencies, bundling them in your distributions, and making them available at compile time and runtime.
The 2.0 version of Maven, scheduled for release in late August, is a complete rewrite of the successful 1.x version. This new version adds many useful features such as integrated multi-project support, transitive dependency management, dependency scoping, a defined life-cycle, a new plugin API, and improved site generation. As a full review of the capabilities of Maven is beyond the scope of this article, please consult the Related Resources section for more information about Maven.
|Author's Note: At the time of publication Maven 2.0 Beta 1 has not yet been released though it is expected soon. The code provided (see left column) works with Alpha 3 as well as the latest code base.
The remainder of this article will focus on the features of Maven new to the 2.0 release and will walk you through building a Java application with Maven 2.0 from the ground up.
Integrated Multi-Project Support
Multi-project support is important when building enterprise Java applications because the complexity of enterprise systems usually requires multiple components working collaboratively to achieve the end goal. Component packaging is core to the J2EE specification. An enterprise application may be packaged as an EAR file comprising multiple WARs, EJB-JARs, and utility JARs, and these components may be interdependent. For example, a servlet packaged in a WAR may use the services provided by an EJB in an EJB-JAR.
Multi-project support in Maven addresses not only the packaging of components in a J2EE-compliant manner but also analyzes these dependencies (through the metadata contained in the POM) and builds the components in the correct order so that artifacts that are depended upon are built before the ones that depend on them.
In Maven 1.0 multi-project support was not inherent to the build system but was instead provided by the multi-project plugin. In Maven 2.0, however, multi-project support is built into the core Maven engine. This eases development by explicitly describing subprojects in the POM, by eliminating the need to define multi-project settings in a properties file, and by not requiring the multi-project plugin to be explicitly invoked.