Maven

Digg This!

Page 2 of 3   « previous page   next page »

The key Maven concepts are described in the following that will aid in achieving build process objective.

Build Lifecycle
A typical project build lifecycle covers: prepare resources, compile sources, prepare test resources, compile test sources, execute test cases, and package component. Based on the best practices adopted in the project build, Maven has defined a sequence of tasks executed during this build lifecycle. Contrary to other build tools, it eases developers on the project from developing the build file for project that defines the list of build tasks and their sequence of execution.

Maven is extendable in that a build lifecycle can be defined on its own and associated with any project.

Configuration files
There are two critical configuration files in Maven: Settings.xml and POM.xml.

Default Settings.xml file is included in the Maven installation bundle and used to configure Maven execution. Unlike POM.xml, it is not project-specific. The configurations done here are local repository location, proxy server details, internal repository and its authentication information.

POM.xml is Maven configuration file for the project and is a one-stop-shop for all things concerning the project. It configures:

• Maven Co-ordinates - Artifacts generated from Maven-enabled projects follow a specific address notation as groupid:artifactid:version that marks their location in the internal repository. The groupid, artifactid, and version are configured in POM.xml so a log4j-1.2.4 artifact will have its groupid as log4j, artifactid as log4j, and version as 1.2.4
• POM Relationships - Maven is capable of handling project relationships like dependencies, inheritance, and aggregation. Inheritance is helpful in cases where certain configurations are unique across projects so these are defined in a 'Super POM' that's inherited by other project POM files. Aggregation is useful in a project that has multiple modules each with its own POM file; these modules are listed in the main project POM file and executed as a group. Dependencies are used to define the dependent projects and are detailed below.
• Other Information - There's a build setting element that's used to configure a project's directory structure and manage plug-ins and reporting elements. Other project information like licenses, organization, developers, and mailing lists are configured here and incorporated into the project site built using Maven.

Dependencies Management
Almost all of the development projects depend on other existing frameworks, utilities, and APIs since this helps the projects to reuse rather than reinvent and so saves time, money, and resources. The projects might put all these dependent components in a folder and have a build tool use them when building the project. These artifacts also need to be maintained along with the project code base to be able to build later time with consistency. Most of the time these dependent components are checked into version management system along with the project code base.

This is not a preferred solution because:
1)  Dependent components (mostly JAR files) are binary files and version management systems are better at handling text files than binary files.
2)  Say there are two projects that depend on the Log4j-1.2.4 component. Each project would then have to maintain a copy of this component in the version management system. This increases the size of the version control database and adds to the hardware cost.
3)  And if a project is dependent on, say, 15 components and all of them are maintained in the version management system then normal operations like checkout and updating the versioning system will be slower.

Therefore, Maven recommends maintaining an enterprise-wide repository that will manage the dependent components and their versions. In Maven-speak these dependent components - and the components generated from the build process - are known as artifacts.

Repositories
Repositories are collections of artifacts that adhere to the Maven repository directory layout. To be a Maven repository artifact, it must live in the groupId/artifactId/version structure whose values are defined in the artifact's POM.xml project.

Maven deals with three kinds of repositories:

• External repository: This Maven repository is located in http://repo1.maven.org and maintained by a bunch of contributors. Open source artifacts are maintained here per the Maven repository structure standard that locates the artifact under its groupid -> artifactid -> version.
• Internal repository: This is an enterprise-wide repository maintained by an organization and holds in-house artifacts and the cache of any artifacts downloaded from an external repository. There are products available that help maintain this artifact repository. One such product is Artifactory, which is used in this process architecture. Artifactory has a friendly Web UI to manage repository like deploy artifact, download artifact, browse repository and manage user security.
• Local repository: Maven maintains a cache of dependent artifacts of the project's built using Maven on local machine. This repository's location is configured in Settings.xml.

Repositories can be local or remote and are a place to store artifacts. Whenever a project has a dependency on an artifact, Maven will first attempt to use a local copy (in the local repository) of the specified artifact. If the artifact doesn't exist in the local repository, it will then attempt to download it from an internal repository. If the artifact isn't in the internal repository either then Maven reaches out to the external repository and downloads the artifact from there. The repository elements in Settings.xml specify the alternate repositories to search.

Page 2 of 3   « previous page   next page »