Maven is a popular open source build tool for Java projects, designed to make build process easy. It uses a declarative approach, where the project structure and contents are described. This approach differs from Ant's task-based approach and make files.
Maven follows some basic concepts -
- Same directory structure for all project contents so that once you are familiar with these standard/default locations, you will be able to navigate within any Maven project you build in the future with much ease,
- Your enterprise project can consists of multiple sub-project, each doing its own bit of activities, e.g. a web project, a number of java project, an ejb project - all of these may be the part of an enterprise project. So, you can create appropriate artifacts for each of the project - war file for web projects, jar for java and ejb projects. Then these artifacts can be clubbed using a standard Maven build to create an Ear for deployment.
- Standard naming conventions
- Another important concept to keep in mind is that everything accomplished in Maven is the result of a plugin executing. There is a plugin for every activity in Maven, be it compiling source code, creating JARs, creating Javadocs, running tests etc.
and these results in a build life-cycle process that allows you to take your software development to the next level. It allows to set up a repository, thus allowing you to enforce company-wide development standards and reduces the time needed to write and maintain build scripts.
A Maven project depends on a pom file. A pom, or Project Object Model, file is an xml file and it resides in the project root directory as pom.xml. It contains the description of project, information about versioning and configuration management, dependencies, application and testing resources among others.
here is a part of such a pom file
This is an example of pom file used in an enterprise java project to create an ear file.
Maven Lifecycle
Just like software development lifecycle, Maven's build lifecycle consists of a series of phases where each phase can perform one or more actions. For example, the compile phase invokes a certain set of goals to compile a set of classes. Instead of invoking plug-ins, the Maven 2 developer invokes a lifecycle phase:
mvn compile.
Some of the more useful Maven 2 lifecycle phases are the following:
The lifecycle phase invokes the plug-ins it needs to do the job. Invoking a lifecycle phase automatically invokes any previous lifecycle phases as well.
Dependecies in Maven
In an enterprise application, you may not need to include all the dependencies in the deployed application. Some JARs are needed only for unit testing, while others will be provided at runtime by the application server. Thus using dependency scoping, Maven lets you use certain JARs only when you really need them and excludes them from the classpath when you don't.
When a dependency is declared within the context of your project, Maven tries to satisfy that dependency by looking in all of the remote repositories to which it has access, in order to find the artifacts that most closely match the dependency request. If a matching artifact is located, Maven transports it from that remote repository to your local repository for project use.
Maven has two types of repositories: local and remote.
Maven usually interacts with your local repository, but when a declared dependency is not present in your local repository Maven searches all the remote repositories to which it has access to find what’s missing.
Local Maven repository
When you install and run Maven for the first time, it will create your local repository and populate it with artifacts as a result of dependency requests. By default, Maven creates your local repository in ~/.m2/repository. You must have a local repository in order for Maven to work. Windows users can check in C:\Documents and Settings\userid\.m2\repository to verify local repository.
Maven follows some basic concepts -
- Same directory structure for all project contents so that once you are familiar with these standard/default locations, you will be able to navigate within any Maven project you build in the future with much ease,
- Your enterprise project can consists of multiple sub-project, each doing its own bit of activities, e.g. a web project, a number of java project, an ejb project - all of these may be the part of an enterprise project. So, you can create appropriate artifacts for each of the project - war file for web projects, jar for java and ejb projects. Then these artifacts can be clubbed using a standard Maven build to create an Ear for deployment.
- Standard naming conventions
- Another important concept to keep in mind is that everything accomplished in Maven is the result of a plugin executing. There is a plugin for every activity in Maven, be it compiling source code, creating JARs, creating Javadocs, running tests etc.
and these results in a build life-cycle process that allows you to take your software development to the next level. It allows to set up a repository, thus allowing you to enforce company-wide development standards and reduces the time needed to write and maintain build scripts.
A Maven project depends on a pom file. A pom, or Project Object Model, file is an xml file and it resides in the project root directory as pom.xml. It contains the description of project, information about versioning and configuration management, dependencies, application and testing resources among others.
here is a part of such a pom file
<project>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.xyz.deptId</groupId>
<artifactId>My-proj-artifact-id</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>MyProj-ear</artifactId>
<name>My Project :: Enterprise Application</name>
<packaging>ear</packaging>
<description>My Project EAR</description>
<dependencies>
<dependency>
<groupId>com.xyz.deptId</groupId>
<artifactId>CommonProj</artifactId>
<version>1.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>com.xyz.deptId</groupId>
<artifactId>WebProj</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>com.xyz.deptId</groupId>
<artifactId>EjbProj</artifactId>
<version>${project.version}</version>
<type>ejb</type>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
This is an example of pom file used in an enterprise java project to create an ear file.
- project - This is the top-level element in all Maven pom.xml files.
- modelVersion - This required element indicates the version of the object model that the POM is using. The version of the model itself changes very infrequently, but it is mandatory in order to ensure stability when Maven introduces new features or other model changes.
- groupId - This element indicates the unique identifier of the organization or group that created the project. The groupId is one of the key identifiers of a project and is typically based on the fully qualified domain name of your organization. For example org.apache.maven.plugins is the designated groupId for all Maven plugins.
- artifactId - This element indicates the unique base name of the primary artifact being generated by this project. A typical artifact produced by Maven would have the form
- . (for example, myapp-1.0.jar). Additional artifacts such as source bundles also use the artifactId as part of their file name. packaging - This element indicates the package type to be used by this artifact (JAR, WAR, EAR, etc.). This not only means that the artifact produced is a JAR, WAR, or EAR, but also indicates a specific life cycle to use as part of the build process. The default value for the packaging element is jar. version - This element indicates the version of the artifact generated by the project. name - This element indicates the display name used for the project. This is often used in Maven's generated documentation, and during the build process for your project, or other projects that use it as a dependency. description - This element provides a basic description of your project.
Just like software development lifecycle, Maven's build lifecycle consists of a series of phases where each phase can perform one or more actions. For example, the compile phase invokes a certain set of goals to compile a set of classes. Instead of invoking plug-ins, the Maven 2 developer invokes a lifecycle phase:
mvn compile.
Some of the more useful Maven 2 lifecycle phases are the following:
generate-sources: Generates any extra source code needed for the application, which is generally accomplished using the appropriate plug-ins compile: Compiles the project source code test-compile: Compiles the project unit tests test: Runs the unit tests (typically using JUnit) in the src/test directory package: Packages the compiled code in its distributable format (JAR, WAR, etc.) integration-test: Processes and deploys the package if necessary into an environment where integration tests can be run install: Installs the package into the local repository for use as a dependency in other projects on your local machine deploy: Done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects
Dependecies in Maven
In an enterprise application, you may not need to include all the dependencies in the deployed application. Some JARs are needed only for unit testing, while others will be provided at runtime by the application server. Thus using dependency scoping, Maven lets you use certain JARs only when you really need them and excludes them from the classpath when you don't.
When a dependency is declared within the context of your project, Maven tries to satisfy that dependency by looking in all of the remote repositories to which it has access, in order to find the artifacts that most closely match the dependency request. If a matching artifact is located, Maven transports it from that remote repository to your local repository for project use.
Maven has two types of repositories: local and remote.
Maven usually interacts with your local repository, but when a declared dependency is not present in your local repository Maven searches all the remote repositories to which it has access to find what’s missing.
Local Maven repository
When you install and run Maven for the first time, it will create your local repository and populate it with artifacts as a result of dependency requests. By default, Maven creates your local repository in ~/.m2/repository. You must have a local repository in order for Maven to work. Windows users can check in C:\Documents and Settings\userid\.m2\repository to verify local repository.
Comments
I think how maven is different from ant, had also been incorporated. Anyways very nice!!