Developing with Mavenby Rob Herbst
When the size and complexity of your project grows, a build tool is the best way to automate the steps required to generate your project. For example, in a typical Java project, each time you build you compile the Java files,
jar the .class files, and generate the Javadocs. These steps can all be automated using a build tool. The
make build tool was invented to work out dependencies for a build, and Ant was developed as a cross-platform, Java-centric alternative, with XML replacing the
Makefile's crazy syntax.
Maven from the Apache Software Foundation will most likely become your build tool of choice after you discover its many features. Not only does it provide an out-of-the-box solution to common build-related tasks, but it also produces a "dashboard" of technical information that enables a development team to track the state of a project.
The Maven Way
As great as Ant is as a build tool, you start out each project's build script having to accomplish the same things: compiling, packaging, and testing your code. You can do anything you want, using the great tasks that are built in, but it is a blank canvas for you to fill in. Anyone that has done this a few times probably has a build script they use as a template to begin any new project. One common problem is reusability of targets, unless you are writing your own custom tasks.
Maven takes a different approach. You fill in the details of your project in an XML file, and a wealth of prebuilt functionality becomes available immediately. What's even better is that you can leverage any Ant task inside of your new Maven project.
Maven provides prebuilt "goals" that will automatically:
- Compile your code.
- Create Javadoc documentation.
- Run unit tests.
- Run source code metrics and analysis.
- Create a report detailing violations of your team's coding standards.
- Create a report of the most recent CVS commits.
- Create a report of the CVS activity, pivoted by file and developer.
- Create HTML cross-referenced source code, and more.
The power in Maven comes from a plethora of excellent plug-ins. A list is viewable at the Maven site. For example, there are plug-ins that create EAR files and control J2EE application servers.
Another interesting feature of Maven is its use of a central repository to access the .jars needed to build your project (similar to Perl's CPAN). You list what .jars and versions you need, and Maven is intelligent enough to go and download them for you. When you run Maven for the first time, or attain a new goal, you will see console output detailing repository access to download any required .jars. This is a great feature that not only makes Maven easier to use and set up, but also saves you a lot of time and the headaches of keeping your own collection of dependencies up to date in a local directory or in your source-code control system.
Maven's ease of use comes from the declarative nature of its configuration. Out of the box, it provides the basic steps that every project needs, and configuration customization is done declaratively in the file that contains your Project Object Model (POM). The POM is XML-based, with clear and descriptive names of the elements and attributes. This makes the editing process easier for the developer. Once you have completed filling out the POM, a large number of prebuilt plug-ins are ready to provide some amazing functionality to your build process.
Maven is also easily customizable, especially if you already know Ant. You can add new functionality or hook into existing processes to add any custom steps by using Ant tasks. Use the maven.xml file to add your custom functionality.
The unit of work in a Maven project is a goal. For example, when you issue the command:
You are instructing Maven to attain the
generate goal of the
site plug-in. If you would like to see a list of all the goals at your disposal, enter:
For any development team, running the
maven site:generate goal and publishing the results on a scheduled basis gives every member of the team a clear view of the status of the project. The first page to look at is the Unit Test report, which gives the team an aggregate dashboard-style report of the test runs.
The Checkstyle plug-in is great for enforcing a coding standard. The generated reports list the summary details of how many errors exist in how many files, followed by a listing for each file of the error and line number. It provides a link to the cross-referenced source code, which makes it easy to track down any offending code.
In fact, the Maven developers use Maven in their own development, so you can check out the results of Checkstyle for Maven itself on their Checkstyle report page, as shown in Figure 1.
Figure 1. Checkstyle Report overview
Under this summary is a line-by-line report on style violations, organized by source file, as shown in Figure 2.
Figure 2. Checkstyle Report details
The CVS plug-ins give you a quick status of the code commits to the repository. The provided reports include:
- Changelog Report: Lists the date, author, files, and comments of the most-recently committed files.
- File Activity Report: Provides details on which files are changing the most.
- Developer Activity Report: Provides statistics on the total number of recent commits and files changed per developer.
These reports are also available for Maven's own development, and a recent Changelog Report is shown in Figure 3.
Figure 3. Changelog report
Pages: 1, 2