What makes a maven

One can easily build their project to jar, war etc. Adding a new dependency is very easy. One has to just write the dependency code in pom file. Cons: Maven needs the maven installation in the system for working and maven plugin for the ide. If the maven code for an existing dependency is not available, then one cannot add that dependency using maven.

When should someone use Maven? One can use the Maven Build Tool in the following condition: When there are a lot of dependencies for the project. Then it is easy to handle those dependencies using maven. When dependency version update frequently.

Then one has to only update version ID in pom file to update dependencies. Continuous builds, integration, and testing can be easily handled by using maven.

Reference- Apache Maven Documentation. Skip to content. Change Language. Related Articles. Table of Contents. Save Article. Improve Article. Like Article. What is Maven? Core Concepts of Maven:. Recommended Articles. Article Contributed By :. Easy Normal Medium Hard Expert. Writing code in comment? Please use ide. You may remember that this is also how you identified your own project in the beginning of the POM file.

The example above needs the org. When this POM file is executed by Maven, the two dependencies will be downloaded from a central Maven repository and put into your local Maven repository. If the dependencies are already found in your local repository, Maven will not download them. Only if the dependencies are missing will they be downloaded into your local repository. Sometimes a given dependency is not available in the central Maven repository.

You can then download the dependency yourself and put it into your local Maven repository. Remember to put it into a subdirectory structure matching the groupId , artifactId and version.

Replace all dots. Then you have your subdirectory structure. The two dependencies downloaded by the example above will be put into the following subdirectories:. An external dependency in Maven is a dependency JAR file which is not located in a Maven repository neither local, central or remote repository.

It may be located somewhere on your local hard disk, for instance in the lib directory of a webapp, or somewhere else. The word "external" thus means external to the Maven repository system - not just external to the project.

Most dependencies are external to the project, but few are external to the repository system not located in a repository. The groupId and artifactId are both set to the name of the dependency. The name of the API used, that is. The scope element value is set to system.

The systemPath element is set to point to the location of the JAR file containing the dependency. The rest of the path is relative from that directory. Snapshot dependencies are dependencies JAR files which are under development. Instead of constantly updating the version numbers to get the latest version, you can depend on a snapshot version of the project. Snapshot versions are always downloaded into your local repository for every build, even if a matching snapshot version is already located in your local repository.

Always downloading the snapshot dependencies assures that you always have the latest version in your local repository, for every build. Here is a version element example:. You can configure how often Maven shall download snapshot dependencies in the Maven Settings File. Sometimes the direct dependencies of your project may clash with the transitive dependencies of the direct dependencies. How do you know which of the two versions will be used? This is also referred to as dependency exclusion.

You specify a dependency exclusion inside the declaration of the dependency which transitive dependency you want to exclude. Here is an example of declaring a Maven dependency exclusion:. With this dependency exclusion declaration in place, whatever version of the excluded dependency that the dependency containing the exclusion is using, will be ignored during Maven's compilation of the project. Maven repositories are directories of packaged JAR files with extra meta data.

It is this meta data that enables Maven to download dependencies of your dependencies recursively, until the whole tree of dependencies is download and put into your local repository. Maven repositories are covered in more detail in the Maven Introduction to Repositories , but here is a quick overview.

Maven searches these repositories for dependencies in the above sequence. First in the local repository, then in the central repository, and third in remote repositories if specified in the POM. Local Repository A local repository is a directory on the developer's computer. This repository will contain all the dependencies Maven downloads. The same Maven repository is typically used for several different projects.

Thus Maven only needs to download the dependencies once, even if multiple projects depends on them e. Your own projects can also be built and installed in your local repository, using the mvn install command. That way your other projects can use the packaged JAR files of your own projects as external dependencies by specifying them as external dependencies inside their Maven POM files.

By default Maven puts your local repository inside your user home directory on your local computer. However, you can change the location of the local repository by setting the directory inside your Maven settings file. Here is how you specify another location for your local repository:. Central Repository The central Maven repository is a repository provided by the Maven community. By default Maven looks in this central repository for any dependencies needed but not found in your local repository.

Maven then downloads these dependencies into your local repository. You need no special configuration to access the central repository. Remote Repository A remote repository is a repository on a web server from which Maven can download dependencies, just like the central repository. A remote repository can be located anywhere on the internet, or inside a local network. A remote repository is often used for hosting projects internal to your organization, which are shared by multiple projects.

For instance, a common security project might be used across multiple internal projects. This security project should not be accessible to the outside world, and should thus not be hosted in the public, central Maven repository.

Instead it can be hosted in an internal remote repository. Dependencies found in a remote repository are also downloaded and put into your local repository by Maven. You can configure a remote repository in the POM file. When Maven builds a software project it follows a build life cycle.

The build life cycle is divided into build phases, and the build phases are divided into build goals. Maven build life cycles, build phases and goals are described in more detail in the Maven Introduction to Build Phases , but here I will give you a quick overview.

Each of these build life cycles takes care of a different aspect of building a software project. Thus, each of these build life cycles are executed independently of each other. You can get Maven to execute more than one build life cycle, but they will be executed in sequence, separately from each other, as if you had executed two separate Maven commands.

The default life cycle handles everything related to compiling and packaging your project. The clean life cycle handles everything related to removing temporary files from the output directory, including generated source files, compiled classes, previous JAR files etc. The site life cycle handles everything related to generating documentation for your project. In fact, site can generate a complete website with documentation for your project.

Build Phases Each build life cycle is divided into a sequence of build phases, and the build phases are again subdivided into goals. Thus, the total build process is a sequence of build life cycle s , build phases and goals.

You can execute either a whole build life cycle like clean or site , a build phase like install which is part of the default build life cycle, or a build goal like dependency:copy-dependencies. Note: You cannot execute the default life cycle directly. You have to specify a build phase or goal inside the default life cycle. When you execute a build phase, all build phases before that build phase in this standard phase sequence are executed.

Thus, executing the install build phase really means executing all build phases before the install phase, and then execute the install phase after that. The default life cycle is of most interest since that is what builds the code. Since you cannot execute the default life cycle directly, you need to execute a build phase or goal from the default life cycle. The default life cycle has an extensive sequence of build phases and goals, ,so I will not describe them all here.

The most commonly used build phases are:. You execute one of these build phases by passing its name to the mvn command. This example executes the package build phase, and thus also all build phases before it in Maven's predefined build phase sequence.

If the standard Maven build phases and goals are not enough to build your project, you can create Maven plugins to add the extra build functionality you need. Build Goals Build goals are the finest steps in the Maven build process. A goal can be bound to one or more build phases, or to none at all. If a goal is not bound to any build phase, you can only execute it by passing the goals name to the mvn command.

If a goal is bound to multiple build phases, that goal will get executed during each of the build phases it is bound to. Maven build profiles enable you to build your project using different configurations. Instead of creating two separate POM files, you can just specify a profile with the different build configuration, and build your project with this build profile when needed.

Here I will give you a quick overview though. Maven build profiles are specified inside the POM file, inside the profiles element. Each build profile is nested inside a profile element. A build profile describes what changes should be made to the POM file when executing under that build profile.

This could be changing the applications configuration file to use etc. The elements inside the profile element will override the values of the elements with the same name further up in the POM. At first glance Maven can appear to be many things, but in a nutshell Maven is an attempt to apply patterns to a project's build infrastructure in order to promote comprehension and productivity by providing a clear path in the use of best practices.

Maven is essentially a project management and comprehension tool and as such provides a way to help with managing:. Now let's move on to how you, the user, can benefit from using Maven. Maven can provide benefits for your build process by employing standard conventions and practices to accelerate your development cycle while at the same time helping you achieve a higher rate of success.

Now that we have covered a little bit of the history and purpose of Maven let's get into some real examples to get you up and running with Maven!

The defaults for Maven are often sufficient, but if you need to change the cache location or are behind a HTTP proxy, you will need to create configuration. See the Guide to Configuring Maven for more information. We are going to jump headlong into creating your first Maven project! To create our first Maven project we are going to use Maven's archetype mechanism. An archetype is defined as an original pattern or model from which all other things of the same kind are made. In Maven, an archetype is a template of a project which is combined with some user input to produce a working Maven project that has been tailored to the user's requirements.

We are going to show you how the archetype mechanism works now, but if you would like to know more about archetypes please refer to our Introduction to Archetypes. On to creating your first project! In order to create the simplest of Maven projects, execute the following from the command line:. Once you have executed this command, you will notice a few things have happened.

First, you will notice that a directory named my-app has been created for the new project, and this directory contains a file named pom. The POM is the basic unit of work in Maven. This is important to remember because Maven is inherently project-centric in that everything revolves around the notion of a project. In short, the POM contains every important piece of information about your project and is essentially one-stop-shopping for finding anything related to your project.

Now let's get back to the project at hand. After the archetype generation of your first project you will also notice that the following directory structure has been created:. As you can see, the project created from the archetype has a POM, a source tree for your application's sources and a source tree for your test sources. If you were to create a Maven project by hand this is the directory structure that we recommend using. This is a Maven convention and to learn more about it you can read our Introduction to the Standard Directory Layout.

Now that we have a POM, some application sources, and some test sources you are probably asking Change to the directory where pom. The first time you execute this or any other command, Maven will need to download all the plugins and related dependencies it needs to fulfill the command.

From a clean installation of Maven, this can take quite a while in the output above, it took almost 4 minutes. If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.

So, if you're a keen observer, you'll notice that by using the standard conventions, the POM above is very small and you haven't had to tell Maven explicitly where any of your sources are or where the output should go. By following the standard Maven conventions, you can get a lot done with very little effort! Just as a casual comparison, let's take a look at what you might have had to do in Ant to accomplish the same thing. Now, this is simply to compile a single tree of application sources and the Ant script shown is pretty much the same size as the POM shown above.

But we'll see how much more we can do with just that simple POM! If you simply want to compile your test sources but not execute the tests , you can execute the following:. Now that you can compile your application sources, compile your tests, and execute the tests, you'll want to move on to the next logical step so you'll be asking Making a JAR file is straight forward enough and can be accomplished by executing the following command:.

For more information on repositories you can refer to our Introduction to Repositories but let's move on to installing our artifact! To do so execute the following command:.

Note that the surefire plugin which executes the test looks for tests contained in files with a particular naming convention. By default the tests included are:. You have walked through the process for setting up, building, testing, packaging, and installing a typical Maven project. This is likely the vast majority of what projects will be doing with Maven and if you've noticed, everything you've been able to do up to this point has been driven by an line file, namely the project's model or POM.

If you look at a typical Ant build file that provides the same functionality that we've achieved thus far you'll notice it's already twice the size of the POM and we're just getting started! There is far more functionality available to you from Maven without requiring any additions to our POM as it currently stands.

To get any more functionality out of our example Ant build file you must keep making error-prone additions. So what else can you get for free? There are a great number of Maven plugins that work out of the box with even a simple POM like we have above.

We'll mention one here specifically as it is one of the highly prized features of Maven: without any work on your part this POM has enough information to generate a web site for your project! You will most likely want to customize your Maven site but if you're pressed for time all you need to do to provide basic information about your project is execute the following command:. This will remove the target directory with all the build data before starting so that it is fresh.

Notice the value of the version tag in the pom. During the release process, a version of x. The release process also increments the development version to x. For example, version 1.

Whenever you want to customise the build for a Maven project, this is done by adding or reconfiguring plugins. For this example, we will configure the Java compiler to allow JDK 5.