I usually put a <dependencyManagement>
section in parent-project/pom.xml
. This <dependencyManagement>
section contains declaration and version for all dependencies of my children modules like this (i.e. without the <scope>
element):
<dependencyManagement> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> </dependency> </dependencies> </dependencyManagement>
In all children modules (i.e. moduleX/pom.xml), I have:
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>test</scope> </dependency> </dependencies>
Obviously, in this example I'm repeating the <scope>test</scope>
multiple times for the same dependency (once in every child module needing junit).
My question is:
What are the best practices regarding <scope>
declaration?
Is it better to put it in the <dependencyManagement>
?
Or is it better to put it in the <dependencies>
section of the child module (like in this post)? And why?
Is there any definitive answer to this question?
Usage. In general, we use the dependencyManagement tag to avoid repeating the version and scope tags when we define our dependencies in the dependencies tag. In this way, the required dependency is declared in a central POM file.
This scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks. compile. This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project.
Dependency management in Maven allows teams to manage dependencies for multi-module projects and applications. These can consist of hundreds or even thousands of modules. Using Maven can help teams define, create, and maintain reproducible builds.
provided scope is only available on the compilation and test classpath, whereas compile scope is available in all classpaths. provided dependencies are not packaged.
A little late to the party, but I'll add my two cents.
I recently ran into a very difficult to debug issue.
I have a parent pom for managing dependencies across multiple projects. I had it set with all the dependencies common amongst them and included groupId
, artifactId
, version
and the most common scope
.
My thinking would be that I would not have to include scope in the actual dependency section in each project if it fell in line with that most common scope
.
The problem occurred when some of those dependencies showed up as transitive dependencies. For example, if:
dependencyManagement
of parent.Then A's transitive dependency on C is determined to be provided. I'm not really sure if that makes sense or not, but it certainly is confusing.
Anyway, save yourself the hassle, and leave scope
out of your dependencyManagement
.
dependencyManagement
is just here to define dependencies version for all project submodules, the only pertinent scope in this section is import
for BOMs.
Scope must be defined in dependencies
section.
(For a given dependency it determines the usage context. It allows to include the dependency only when it is required for execution. For example an ear will not be packaged with Java-ee dependencies (scope provided
) as it will find them on the target server.)
[edit]
The first statement has an exception, the scope provided
in dependencyManagement
section will override defined scope in dependencies
sections. see DependencyManagement to force scope
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With