It is a bit complex, If you are building a maven project the first time. In my case, I spent a lot of time setting up my first maven project. While building the project, If I got some error, then I search the error in StackOverflow, find a solution, apply it. Sometime it will work and sometimes it won't. I am just applying the StackOverflow recommended solution without understanding it. But later, I realize this is why I took a lot of time to fix a problem. First, I understand the problem before fixing it. This saved a lot of time from fixing the problem if it occurs on the next time.
In this article, we are discussing the basic maven building issues, and what is the reason behind those issues, and how can we fix those issues. Once you finish this article, you will get an idea about what to do if you face some basic dependency problems.
Let's get started…
Let's starts with the basic dependency addition in maven.
How to add a dependency in Maven?
The basic use of maven is resolving dependencies. Before maven it is very tough to handle dependencies The developer wants to sort out all the required jar for the project, then he needs to add those jars on the classpath of the project. Here the main problem is the developer needs to spend a lot of time for resolving dependent jars without conflicting the versions. Also, the project size becomes so large because the dependent jars are included as part of the project. The maven resolved these kinds of issues with its dependencies handling. The centralized file of a maven project is pom.xml, and inside the file, it is mentioning the details about dependencies about the project.
In maven the dependencies are handled by using the tag <dependency>inside of <dependencies> tag and it have three mandatory child elements. Those are groupId, artifactId and version.
groupId: The groupId is generally the unique id for the organization. Generally, its name comes like a package name. Say example:
artifactId: Is the exact name of the project under the organization. Say example: slf4j-API, commons-collections, commons-io…etc.
version: The term version indicate the version number for the artefact. With the version number, it is possible to mention the type of build like Final, alpha, beta, snapshot …etc. Here are some examples of version format
Let's move on to create a simple maven project which includes a single dependency of commons-lang3.
The above code snippets show a simple maven project with commons-lang3 dependency added.
But I can see some dependency tags without version tag, How this happening?
In the large project, you can see that the dependency tag without versions, especially in the case of multimodule projects. So in these kinds of project from where these version is resolving…
In the case of multimodule project, the same dependency is shared on different sub-projects. In those situations, if the dependency version is different on different sub-project, then the final build of the main project contains the same jars with different versions. That may impact the build.
For resolving this, the maven introduced <dependencyManagement> tag. In dependencyManagement tag, it can define the dependency with versions. So if there is a dependency without version found on the dependencies tag, then first it will search on the dependencyManagement tag then check if it is possible to resolve the dependency.
Let's move on to the same example discussed above by adding the tag dependencyManagement.
In the above code snippet the inside the
dependencyManagement tag, it is defined as the
commons-lang3 dependency with version. In
dependencies tag, it is just defined the
commons-lang3 dependency without version, and it is resolved from the dependencyManagement tag.
What is the use of the dependencyManagement tag?
The dependencyManagement tag allows centralized management of dependency versions. This is very useful in the case of multiple modules which sharing the same dependency. You can define the dependencyManagement on the parent pom, and in the child pom, it can mention the dependency without mentioning the version. This will eliminate the problem of multiple versions of the same jar coming on the build.
If I add the dependency inside dependencyManagement, the dependency already added on the project?
This doubt came to me initially. When I build the project, it shows not able to compile. But when I check the
pom.xml, I can see the dependency mentioned under
dependencyManagement tag. After I realize that the dependencyManagement tag is using for just defining a dependency. It is applied only after it is rewritten on
I want to exclude a dependency as part of a dependency. How is it possible in maven?
Sometimes you can see multiple versions of the same jar in your build and it causing some problems while execution of the build, but if you check the pom you cant see that dependency, but it is coming as part of some other dependency.
Inside of the
<dependency>tag, it can exclude the dependency with the help of
Let's explore the term exclusion with an example. Consider the below
Here the dependency hierarchy and resolved dependency look like follows.
Here just note, the resolved dependency of
commons-logging. The maven resolved dependency for the jar is
1.0.2 , but there is a higher version of
commons-beanutil-1.7.0 jar. It was omitted because of
commons-logging conflict. But I need the
1.0.3 version of commons-logging on the resolved dependency. How is it possible?
It is possible with the help of the
exclusion tag. Here follows the updated
Here added the exclusion from
jasperreports. So it considers the
commons-logging dependency as part of
Is it possible to mention a range of versions on pom?
In the version tag, it is possible to mention a range of versions. The version ranges can mention in using [,],(,) tags. Here are some examples of version ranges.
It is able to mention the version ranges using the tags such as [,],(,). Here below shows the examples of these using different tags.
(,1.0]: This will take all version below or equal to 1.0
[1.0]: exact 1.0 version
[1.2,1.3]: version between 1.2 and 1.3, including both
[1.0,2.0): version between 1.0 and 2.0 but not including 2.0
[1.5,): version greater than 1.5, including 1.5
(,1.0],[1.2,): x <= 1.0 or x >= 1.2.
(,1.1),(1.1,): This excludes 1.1 if it is known not to work in combination with the library.
In this article, we discussed the very basics about maven. Going forward will see more advanced topics about maven and can become an expert in it.