I'm trying to create a maven spring-boot project with multiple modules. I have created a parent module with packaging type pom and many children submodules with packaging type jar.
So my parent's pom.xml looks like:
<groupId>Creator</groupId>
<artifactId>DPAI</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<modules>
<module>starter</module>
<module>DatabaseApi</module>
...
</modules>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.2.4.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
One of submodules: starter contains only starting class annotated with #SpringBootApplicatoion and in its pom.xml there is a section with other child artifacts like:
<parent>
<artifactId>DPAI</artifactId>
<groupId>Creator</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>starter</artifactId>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>Creator</groupId>
<artifactId>DatabaseApi</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
...
</dependencies>
So I'm trying to do some refactoring and move Main.class and all dependencies to my parent's pom, but it doesn't compile with error with message that my dependencies referencing itself.
In my opinion, the problem is that my parent pom contains section with it's own submodules. Parent of that submoduls is the same pom, where I try to add described dependencies
The parent.pom can't contain any java code, only Maven specifics e.g. See: https://howtodoinjava.com/maven/maven-parent-child-pom-example/#parent-content
Maybe tell us, what you want to achieve.
In a Maven multi module project you usually have a parent Pom (with packaging Pom) and several modules at the same level as you already set your project up.
Build the modules without dependecies on your code first, the the dependent modules: In your parent Pom change the order of the modules to
<modules>
<module>DatabaseApi</module>
<module>starter</module>
...
</modules>
So I'm trying to do some refactoring and move Main.class and all
dependencies to my parent's pom
I dont think this is possible. Your parent pom is actually of type pom, meaning you're not actually supposed to have any java code in it. Its meant to hold the versions of jars used in your child modules. You can relate this to the spring-boot-parent module. When we declare the spring-boot-parent module in a spring boot project, your adding your project as a child of the spring-boot-parent. And the parent will manage the versions of all of your dependencies.
I think the best way forward would be to maintain all your service related code in your spring-boot module. Filters, controllers,etc. The other stuff like your jdbc, integration layers can be maintained in other child modules and then referred to the spring module as jar references similar to your example.
So I'm trying to do some refactoring and move Main.class and all
dependencies to my parent's pom,
I'm not 100% sure if Maven would support something like the following in the parent POM itself:
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>DatabaseApi</artifactId>
<version>${project.version}</version>
</dependency>
...
</dependencies>
But for sure it won't support Java classes in a Module with pom-packaging (such as parent modules or multi-module modules). The compiler:compile goal etc. are not bound to any phase for pom-packaging by default. In other words: Maven does not compile Java classes for pom-modules by default.
My recommendation:
Keep the SpringBootApplication in a Java-based module. For Spring MVC/ WebFlux application I usually create a "-web" module with:
SpringBootApplication
web service controllers
http/ web filters
global configs such as: security, swagger, async
application.yml
...
It's also the module where I configure the Spring Boot Plugin to create an executable JAR.
What is the difference between dependencyManagement and dependencies?
I have seen the docs at Apache Maven web site.
It seems that a dependency defined under the dependencyManagement can be used in its child modules without specifying the version.
For example:
A parent project (Pro-par) defines a dependency under the dependencyManagement:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8</version>
</dependency>
</dependencies>
</dependencyManagement>
Then in the child of Pro-par, I can use the junit:
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
</dependencies>
However, I wonder if it is necessary to define junit in the parent pom? Why not define it directly in the needed module?
I'm fashionably late to this question, but I think it's worth a clearer response than the accepted one (which is correct, but doesn't emphasize the actual important part, which you need to deduce yourself).
In the parent POM, the main difference between the <dependencies> and <dependencyManagement> is this:
Artifacts specified in the <dependencies> section will ALWAYS be included as a dependency of the child module(s).
Artifacts specified in the <dependencyManagement> section, will only be included in the child module if they were also specified in the <dependencies> section of the child module itself. Why is it good you ask? Because you specify the version and/or scope in the parent, and you can leave them out when specifying the dependencies in the child POM. This can help you use unified versions for dependencies for child modules, without specifying the version in each child module.
Dependency Management allows to consolidate and centralize the management of dependency versions without adding dependencies which are inherited by all children. This is especially useful when you have a set of projects (i.e. more than one) that inherits a common parent.
Another extremely important use case of dependencyManagement is the control of versions of artifacts used in transitive dependencies. This is hard to explain without an example. Luckily, this is illustrated in the documentation.
The documentation on the Maven site is horrible. What dependencyManagement does is simply move your dependency definitions (version, exclusions, etc) up to the parent pom, then in the child poms you just have to put the groupId and artifactId. That's it (except for parent pom chaining and the like, but that's not really complicated either - dependencyManagement wins out over dependencies at the parent level - but if have a question about that or imports, the Maven documentation is a little better).
After reading all of the 'a', 'b', 'c' garbage on the Maven site and getting confused, I re-wrote their example. So if you had 2 projects (proj1 and proj2) which share a common dependency (betaShared) you could move that dependency up to the parent pom. While you are at it, you can also move up any other dependencies (alpha and charlie) but only if it makes sense for your project. So for the situation outlined in the prior sentences, here is the solution with dependencyManagement in the parent pom:
<!-- ParentProj pom -->
<project>
<dependencyManagement>
<dependencies>
<dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
<groupId>alpha</groupId>
<artifactId>alpha</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>zebra</groupId>
<artifactId>zebra</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
<artifactId>charlie</artifactId>
<version>1.0</version>
<type>war</type>
<scope>runtime</scope>
</dependency>
<dependency> <!-- defining betaShared here makes a lot of sense -->
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<version>1.0</version>
<type>bar</type>
<scope>runtime</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
<!-- Child Proj1 pom -->
<project>
<dependencies>
<dependency>
<groupId>alpha</groupId>
<artifactId>alpha</artifactId> <!-- jar type IS DEFAULT, so no need to specify in child projects -->
</dependency>
<dependency>
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
</dependencies>
</project>
<!-- Child Proj2 -->
<project>
<dependencies>
<dependency>
<groupId>charlie</groupId>
<artifactId>charlie</artifactId>
<type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
<dependency>
<groupId>betaShared</groupId>
<artifactId>betaShared</artifactId>
<type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
</dependency>
</dependencies>
</project>
There's still one thing that is not highlighted enough, in my opinion, and that is unwanted inheritance.
Here's an incremental example:
I declare in my parent pom:
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
</dependencies>
boom! I have it in my Child A, Child B and Child C modules:
Implicilty inherited by child poms
A single place to manage
No need to redeclare anything in child poms
I can still redelcare and override to version 18.0 in a Child B if I want to.
But what if I end up not needing guava in Child C, and neither in the future Child D and Child E modules?
They will still inherit it and this is undesired!
This is just like Java God Object code smell, where you inherit some useful bits from a class, and a tonn of unwanted stuff as well.
This is where <dependencyManagement> comes into play. When you add this to your parent pom, all of your child modules STOP seeing it. And thus you are forced to go into each individual module that DOES need it and declare it again (Child A and Child B, without the version though).
And, obviously, you don't do it for Child C, and thus your module remains lean.
It's like you said; dependencyManagement is used to pull all the dependency information into a common POM file, simplifying the references in the child POM file.
It becomes useful when you have multiple attributes that you don't want to retype in under multiple children projects.
Finally, dependencyManagement can be used to define a standard version of an artifact to use across multiple projects.
Sorry I am very late to the party.
Let me try to explain the difference using mvn dependency:tree command
Consider the below example
Parent POM - My Project
<modules>
<module>app</module>
<module>data</module>
</modules>
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>19.0</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.9</version>
</dependency>
</dependencies>
</dependencyManagement>
Child POM - data module
<dependencies>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
</dependency>
</dependencies>
Child POM - app module (has no extra dependency, so leaving dependencies empty)
<dependencies>
</dependencies>
On running mvn dependency:tree command, we get following result
Scanning for projects...
------------------------------------------------------------------------
Reactor Build Order:
MyProject
app
data
------------------------------------------------------------------------
Building MyProject 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-dependency-plugin:2.8:tree (default-cli) # MyProject ---
com.iamvickyav:MyProject:pom:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile
------------------------------------------------------------------------
Building app 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-dependency-plugin:2.8:tree (default-cli) # app ---
com.iamvickyav:app:jar:1.0-SNAPSHOT
\- com.google.guava:guava:jar:19.0:compile
------------------------------------------------------------------------
Building data 1.0-SNAPSHOT
------------------------------------------------------------------------
--- maven-dependency-plugin:2.8:tree (default-cli) # data ---
com.iamvickyav:data:jar:1.0-SNAPSHOT
+- org.apache.commons:commons-lang3:jar:3.9:compile
\- com.google.guava:guava:jar:19.0:compile
Google guava is listed as dependency in every module (including parent), whereas the apache commons is listed as dependency only in data module (not even in parent module)
There are a few answers outlining differences between <depedencies> and <dependencyManagement> tags with maven.
However, few points elaborated below in a concise way:
<dependencyManagement> allows to consolidate all dependencies (used at child pom level) used across different modules -- clarity, central dependency version management
<dependencyManagement> allows to easily upgrade/downgrade dependencies based on need, in other scenario this needs to be exercised at every child pom level -- consistency
dependencies provided in <dependencies> tag is always imported, while dependencies provided at <dependencyManagement> in parent pom will be imported only if child pom has respective entry in its <dependencies> tag.
If the dependency was defined in the top-level pom's dependencyManagement element, the child project did not have to explicitly list the version of the dependency. if the child project did define a version, it would override the version listed in the top-level
POM’s dependencyManagement section. That is, the dependencyManagement version is only
used when the child does not declare a version directly.
Just in my own words, your parent-project helps you provide 2 kind of dependencies:
implicit dependencies : all the dependencies defined in the <dependencies> section in your parent-project are inherited by all the child-projects
explicit dependencies : allows you to select, the dependencies to apply in your child-projects. Thus, you use the <dependencyManagement> section, to declare all the dependencies you are going to use in your different child-projects. The most important thing is that, in this section, you define a <version> so that you don't have to declare it again in your child-project.
The <dependencyManagement> in my point of view (correct me if I am wrong) is just useful by helping you centralize the version of your dependencies. It is like a kind of helper feature.
As a best practice, your <dependencyManagement> has to be in a parent project, that other projects will inherit. A typical example is the way you create your Spring project by declaring the Spring parent project.
The difference between the two is best brought in what seems a necessary and sufficient definition of the dependencyManagement element available in Maven website docs:
dependencyManagement
"Default dependency information for projects that inherit from this one. The dependencies in this section are not immediately resolved. Instead, when a POM derived from this one declares a dependency described by a matching groupId and artifactId, the version and other values from this section are used for that dependency if they were not already specified."
[ https://maven.apache.org/ref/3.6.1/maven-model/maven.html ]
It should be read along with some more information available on a different page:
“..the minimal set of information for matching a dependency reference against a dependencyManagement section is actually {groupId, artifactId, type, classifier}. In many cases, these dependencies will refer to jar artifacts with no classifier. This allows us to shorthand the identity set to {groupId, artifactId}, since the default for the type field is jar, and the default classifier is null.” [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html ]
Thus, all the sub-elements (scope, exclusions etc.,) of a dependency element--other than groupId, artifactId, type, classifier, not just version--are available for lockdown/default at the point (and thus inherited from there onward) you specify the dependency within a dependencyElement. If you’d specified a dependency with the type and classifier sub-elements (see the first-cited webpage to check all sub-elements) as not jar and not null respectively, you’d need {groupId, artifactId, classifier, type} to reference (resolve) that dependency at any point in an inheritance originating from the dependencyManagement element. Else, {groupId, artifactId} would suffice if you do not intend to override the defaults for classifier and type (jar and null respectively). So default is a good keyword in that definition; any sub-element(s) (other than groupId, artifactId, classifier and type, of course) explicitly assigned value(s) at the point you reference a dependency override the defaults in the dependencyManagement element.
So, any dependency element outside of dependencyManagement, whether as a reference to some dependencyManagement element or as a standalone is immediately resolved (i.e. installed to the local repository and available for classpaths).
I do not recommend using dependencyManagement.
The only benefit of using it is that you can define the version in parent pom and do not need to define it again in child pom. But if you have a set of projects (especially micro-service projects). Using dependencyManagement has no benefits.
Different projects may need different dependency. Why inherit it from the same parent pom. Keep it as simple as possible. If one project needs A dependency, then add it to the pom file. Don't confuse developers.
In Eclipse, there is one more feature in the dependencyManagement. When dependencies is used without it, the unfound dependencies are noticed in the pom file. If dependencyManagement is used, the unresolved dependencies remain unnoticed in the pom file and errors appear only in the java files. (imports and such...)
One use case of <dependencyManagement> is for resolving library versions conflict.
Example:
Project A have library x:1.0.1
Project A have B library
B library have library x:1.0.0
Having this set you will get conflict having project A both x:1.0.1 and x:1.0.0.
To resolve this you can put dependency with specific version into <dependencyManagement> tag
If you have a parent-pom anyways, then in my opinion using <dependencyManagement> just for controlling the version (and maybe scope) is a waste of space and confuses junior developers.
You will probably have properties for versions anyways, in some kind of parent-pom file. Why not just use this properties in the child pom's? That way you can still update a version in the property (within parent-pom) for all child projects at once. That has the same effect as <dependencyManagement> just without <dependencyManagement>.
In my opinion, <dependencyManagement> should be used for "real" management of dependencies, like exclusions and the like.
It was explained by here to be easy to understand.
The conclusion difference between dependencyManagement & dependencies are declaration and actually addition
I'm working with Maven to management the dependencies of my projects. I have my parent POM and I'm using Dependency Management to avoid write the common dependencies in each project.
Now, I need change the version of one dependency in my child POM.
I have this of my parent POM
<dependencyManagement>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.1</version>
</dependency>
</dependencyManagement>
My child POM has a reference to the parent POM
<parent>
<groupId>com.myproject</groupId>
<artifactId>root-parent-pom</artifactId>
<version>1.1.0.22</version>
<relativePath>../parent/pom.xml</relativePath>
</parent>
And in this child POM I want to override the version of the same dependency that I wrote in the parent POM, something like this.
<dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.6</version>
</dependency>
</dependency>
I did that, but when I generate my project, in this case is a WAR, the final version of the dependency that is included in my project is the version that is described on the parent POM.
Is possible override the version in child POM?
Maybe. If you specify a distinct version, then this version will override the one in the dependencyManagement element.
But only for this single POM. It doesn't magically distribute to the next POM in the reactor build unless the next POM has this POM as parent. So if you have this setup:
parent
- mod1
- mod2
- war
and you put this into mod1, then the war won't notice since war uses parent as parent POM. The dependency mod1 says "please use 2.6" but that's the same as any other pom which uses 2.1 - there is no reason to prefer that over the other. That's the power of dependencyManagement: You get a single place where you can control the versions of all transitive dependencies.
Try mvn help:effective-pom to see what Maven will use in each part of your build.
To make the WAR pick up the overwritten version, you need to specify it in the parent POM of the WAR or in the WAR's POM itself.
The usual solution is to have a parent POM for all projects which sets the default versions (2.1). Then you have a parent POM per project which inherits from the global parent POM. Here you can set the version to 2.6. Since all modules of the project inherit from it, the per-project parent POM takes precedence.
You need to define that dependency in a war project.
Is it possible to use an aggregating module (pom that aggregates modules for building purposes) as a dependency that transitively includes its modules as dependencies? Considering it must declare those dependencies that correspond to its submodules, otherwise if you declare it as a dependency, it hasn't own dependencies, so that no transitive deps are included.
I already tried it but I got a cyclic dependency error.
Otherwise I would have to create an extra module (say my_module_deps) that just declares all those dependencies, so I could use it as a dependency that transitively includes its dependencies. I don't like having maven modules that do not have any specific purpose except for being a dependency bulk.
This is the desired state, so I can use it for both module aggregation and a dependency to be used for getting its transitive dependencies :
<project>
<artifactId>aggregationModule</artifactId>
<modules>
<module>a</module>
<module>b</module>
<module>c</module>
</modules>
<dependencies>
<dependency>
<artifactId>a</artifactId>
</dependency>
<dependency>
<artifactId>b</artifactId>
</dependency>
<dependency>
<artifactId>c</artifactId>
</dependency>
</dependencies>
</project>
Do any of the sub-modules have that aggregating project defined as its parent?
If so, this cannot work, since for being parent the project must be build first.
But if the parent itself defines the modules as dependencies at the same time, the modules must be build first, so you created your cyclic dependency error.
You cannot declare a dependency to a project with packaging type "pom". If you do so maven will show the same error as when you declare a dependency to a jar module which does not exists in your local repository and could not be downloaded from your repository list.
Maybe some of the alternatives proposed to this question could help you.