Java Reference
In-Depth Information
that, we present some real-world examples of compiling your test cases and running
them as well as producing fancy reports.
By the end of this chapter, you'll know how to set up your environment on your
machine to build Java projects with Maven, including managing their dependencies,
executing
JU
nit tests, and generating
JU
nit reports.
10.1
Maven's features
Once you've used Ant on several projects, you'll notice that projects almost always
need the same Ant scripts (or at least a good percentage of them). These scripts are
easy enough to reuse through cutting and pasting, but each new project requires a bit
of fussing to get the Ant buildfiles working just right. In addition, each project usually
ends up having several subprojects, each of which requires you to create and maintain
an Ant buildfile. Maven (
http://maven.apache.org/
) picks up where Ant leaves off,
making it a natural fit for many teams. Like Ant, Maven is a tool for running other
tools, but Maven is designed to take tool reuse to the next level. If Ant is a source-
building framework, then Maven is a source-building
environment
.
In order to understand better how Maven works, you need to understand the key
points (principles) behind Maven. Maven was designed to take the build systems to
the next level, beyond Ant. You need to become familiar with the things that the
Maven community didn't like in Ant and how it tried to avoid them in designing
Maven, that is, the core reason for starting Maven as a whole new project.
From the beginning of the Maven project, certain ground rules were in place for
the entire software architecture of the project. These rules aim to simplify develop-
ment with Maven and to make it easier for developers to implement the build system.
One of the fundamental ideas of Maven is that the build system should be as simple as
possible—software engineers should not spend a lot of time implementing the build
system. It should be easy enough to start a new project from scratch and then rapidly
begin developing the software, not spend valuable time designing and implementing
a build system.
In this section we describe each of the core Maven principles in detail, and we
explain what they mean to us, from a developer's point of view.
10.1.1
Convention over configuration
This feature is a software design principle that aims to decrease the number of config-
urations a software engineer needs to make, in favor of introducing a number of con-
ventional rules that the developers need to follow. This way you, as a developer, can
skip the tedious configuration required for every single project, and you can focus on
the more important parts of your work.
Convention over configuration is one of the strongest principles of the Maven proj-
ect. As an example of its application, let's look at the directory structure of the build
process. When the Maven project was started, some of the initial Maven developers
noticed that for every Ant buildfile, the person who writes the buildfile has to design
