|
|
|
|
Maven is a high-level, intelligent project management,
build and deployment tool provided by Apache’s software
foundation group. Maven deals with application development
lifecycle management. Maven was originally developed
to manage and to minimize the complexities of
building the Jakarta Turbine project. But its powerful
capabilities have made it a core entity of the Apache
Software Foundation projects. Actually, for a long time
there was a need to standardized project development
lifecycle management system and Maven has emerged
as a perfect option that meets the needs. Maven has
become the de- facto build system in many open source
initiatives and it is rapidly being adopted by many software
development organizations.
Maven was borne of the very practical desire to make several
projects at Apache work in a consistence manner. So that
developers could freely move between these projects, knowing
clearly how they all worked by understanding how one of them
worked.
If a developer spent time understanding how one project built
it was intended that they would not have to go through this
process again when they moved on to the next project. The
same idea extends to testing, generating ocumentation,
generating metrics and reports, testing and deploying. All
projects share enough of the same characteristics, an
understanding of which Maven tries to harness in its general
approach to project management.
On a very high level all projects need to be built, tested,
packaged, documented and deployed. There occurs infinite
variation in each of the above mentioned steps, but these
variation still occur within the confines of a well defined path
and it is this path that Maven attempts to present to everyone
in a clear way. The easiest way to make a path clear is to
provide people with a set of patterns that can be shared by
anyone involved in a project.
The key benefit of this approach is that developers can follow
one consistent build lifecycle management process without
having to reinvent such processes again. Ultimately this
makes developers more productive, agile, disciplined, and
focused on the work at hand rather than spending time and
effort doing grunt work understanding, developing, and configuring
yet another non-standard build system.
Shifting from Ant to Maven
Maven is entirely a different creature from Ant. Ant is
simply a toolbox whereas Maven is about the application
of patterns in order to achieve an infrastructure which
displays the characteristics of visibility, reusability,
maintainability, and comprehensibility. It is wrong to
consider Maven as a build tool and just a replacement
for Ant. |
|
There is nothing that Maven does that Ant cannot do. Ant
gives the ultimate power and flexibility in build and deployment
to the developer. But Maven adds a layer of
abstraction above Ant (and uses Jelly). Maven can be
used to build any Java application. Today JEE build and
deployment has become much standardized. Every
enterprise has some variations, but in general it is all the
same: deploying EARs, WARs, and EJB-JARs. Maven
captures this intelligence and lets you achieve the build
and deployment in about 5-6 lines of Maven script compared
to dozens of lines in an Ant build script.
Ant lets you do any variations you want, but requires a lot of
scripting. Maven on the other hand mandates certain directories
and file names, but it provides plugins to make life easier.
The restriction imposed by Maven is that only one artifact is
generated per project (A project in Maven terminology is a
folder with a project.xml file in it). A Maven project can have
sub projects. Each sub project can build its own artifact. The
topmost project can aggregate the artifacts into a larger one.
This is synonymous to jars and wars put together to form an
EAR. Maven also provides inheritance in projects.
Maven simplifies build enormously by imposing certain fixed
file names and acceptable restrictions like one artifact per
project. Artifacts are treated as files on your computer by the
build script. Maven hides the fact that everything is a file and
forces you to think and script to create a deployable artifact
such as an EAR. Artifact has a dependency on a particular
version of a third party library residing in a shared remote (or
local) enterprise repository, and then publish your library into
the repository as well for others to use. Hence there are no
more classpath issues. No more mismatch in libraries. It also
gives the power to embed even the Ant scripts within Maven
scripts if absolutely essential.
Some of the common concerns while building a project
are :
I Project directory structure: The directory structure of
a Web application project is different from that of an
EJB application project. Similarly the output of a Web
application project is typically a WAR file while that of
an EJB application is a JAR file.
II Directory naming conventions: For a specific project
type, the typical requirements in terms of directory
layout and naming conventions are almost the same.
Without a unified framework such as Maven, developers
mostly spend time in configuring such nitty details like
setting up directories for source, resources, test case
source, testing time resources, classes, and project
dependencies.
III The build output: Developers spend a good chunk of
time in creating build scripts such as ANT scripts to
execute build tasks according to the project layout. This
entire endeavor ends up being chaotic and in a largescale
project it can lead to a maintenance nightmare
demanding dedicated resources just to focus on such
build aspects. |
|
August 2007 | Java Jazz Up | 18 |
| |
|
| |
| Pages: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, |
| 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 Download PDF |
|
|
|
|
|
| |
| |
|
