Maven 2

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