Differences between dependencyManagement and dependencies in Maven

Question

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    lt dependencyManagement gt     lt dependencies gt       lt dependency gt         lt groupId gt junit lt  groupId gt         lt artifactId gt junit lt  artifactId gt         lt version gt 3 8 lt  version gt       lt  dependency gt    lt  dependencies gt   lt  dependencyManagement gt    Then in the child of Pro-par  I can use the junit      lt dependencies gt       lt dependency gt         lt groupId gt junit lt  groupId gt         lt artifactId gt junit lt  artifactId gt       lt  dependency gt    lt  dependencies gt    However  I wonder if it is necessary to define junit in the parent pom  Why not define it directly in the needed module

User · Answer

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 unsolved dependencies remain unnoticed in the pom file and errors appear only in the java files   imports and such

User · Answer

If you have a parent-pom anyways  then in my opinion using  lt dependencyManagement gt  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  lt dependencyManagement gt  just without  lt dependencyManagement gt   In my opinion   lt dependencyManagement gt  should be used for  quot real quot  management of dependencies  like exclusions and the like

User · Answer

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  lt dependencies gt  and  lt dependencyManagement gt  is this   Artifacts specified in the  lt dependencies gt  section will ALWAYS be included as a dependency of the child module s    Artifacts specified in the  lt dependencyManagement gt  section  will only be included in the child module if they were also specified in the  lt dependencies gt  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

User · Answer

In the parent POM  the main difference between the   lt dependencies gt  and  lt dependencyManagement gt  is this  Artifacts specified in the  lt dependencies gt  section will ALWAYS be included as a dependency of the child module s   Artifacts specified in the  lt dependencyManagement gt  section will only be included in the child module if they were also specified in the  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

User · Answer

Just in my own words  your parent-project helps you provide 2 kind of dependencies   implicit dependencies   all the dependencies defined in the  lt dependencies gt  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  lt dependencyManagement gt  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  lt version gt  so that you don t have to declare it again in your child-project   The  lt dependencyManagement gt  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  lt dependencyManagement gt  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

User · Answer

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    lt  -- ParentProj pom -- gt   lt project gt     lt dependencyManagement gt       lt dependencies gt         lt dependency gt   lt  -- not much benefit defining alpha here  as we only use in 1 child  so optional -- gt           lt groupId gt alpha lt  groupId gt           lt artifactId gt alpha lt  artifactId gt           lt version gt 1 0 lt  version gt           lt exclusions gt             lt exclusion gt               lt groupId gt zebra lt  groupId gt               lt artifactId gt zebra lt  artifactId gt             lt  exclusion gt           lt  exclusions gt         lt  dependency gt         lt dependency gt           lt groupId gt charlie lt  groupId gt   lt  -- not much benefit defining charlie here  so optional -- gt           lt artifactId gt charlie lt  artifactId gt           lt version gt 1 0 lt  version gt           lt type gt war lt  type gt           lt scope gt runtime lt  scope gt         lt  dependency gt         lt dependency gt   lt  -- defining betaShared here makes a lot of sense -- gt           lt groupId gt betaShared lt  groupId gt           lt artifactId gt betaShared lt  artifactId gt           lt version gt 1 0 lt  version gt           lt type gt bar lt  type gt           lt scope gt runtime lt  scope gt         lt  dependency gt       lt  dependencies gt     lt  dependencyManagement gt   lt  project gt    lt  -- Child Proj1 pom -- gt   lt project gt     lt dependencies gt       lt dependency gt         lt groupId gt alpha lt  groupId gt         lt artifactId gt alpha lt  artifactId gt    lt  -- jar type IS DEFAULT  so no need to specify in child projects -- gt       lt  dependency gt       lt dependency gt         lt groupId gt betaShared lt  groupId gt         lt artifactId gt betaShared lt  artifactId gt         lt type gt bar lt  type gt   lt  -- This is not a jar dependency  so we must specify type  -- gt       lt  dependency gt     lt  dependencies gt   lt  project gt    lt  -- Child Proj2 -- gt   lt project gt     lt dependencies gt       lt dependency gt         lt groupId gt charlie lt  groupId gt         lt artifactId gt charlie lt  artifactId gt         lt type gt war lt  type gt   lt  -- This is not a jar dependency  so we must specify type  -- gt       lt  dependency gt       lt dependency gt         lt groupId gt betaShared lt  groupId gt          lt artifactId gt betaShared lt  artifactId gt          lt type gt bar lt  type gt   lt  -- This is not a jar dependency  so we must specify type  -- gt       lt  dependency gt     lt  dependencies gt   lt  project gt

User · Answer

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    lt dependencies gt           lt dependency gt               lt groupId gt com google guava lt  groupId gt               lt artifactId gt guava lt  artifactId gt               lt version gt 19 0 lt  version gt           lt  dependency gt   lt  dependencies gt    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  lt dependencyManagement gt  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

User · Answer

It s like you said  dependencyManagementis 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

User · Answer

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

User · Answer

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   lt modules gt       lt module gt app lt  module gt       lt module gt data lt  module gt   lt  modules gt    lt dependencies gt       lt dependency gt           lt groupId gt com google guava lt  groupId gt           lt artifactId gt guava lt  artifactId gt           lt version gt 19 0 lt  version gt       lt  dependency gt   lt  dependencies gt    lt dependencyManagement gt       lt dependencies gt           lt dependency gt               lt groupId gt org apache commons lt  groupId gt               lt artifactId gt commons-lang3 lt  artifactId gt               lt version gt 3 9 lt  version gt           lt  dependency gt       lt  dependencies gt   lt  dependencyManagement gt    Child POM - data module   lt dependencies gt       lt dependency gt           lt groupId gt org apache commons lt  groupId gt           lt artifactId gt commons-lang3 lt  artifactId gt       lt  dependency gt   lt  dependencies gt    Child POM - app module  has no extra dependency  so leaving dependencies empty      lt dependencies gt   lt  dependencies gt    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

User · Answer

There are a few answers outlining differences between  lt depedencies gt  and  lt dependencyManagement gt  tags with maven   However  few points elaborated below in a concise way     lt dependencyManagement gt  allows to consolidate all dependencies  used at child pom level  used across different modules -- clarity  central dependency version management  lt dependencyManagement gt  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  lt dependencies gt  tag is always imported  while dependencies provided at  lt dependencyManagement gt  in parent pom will be imported only if child pom has respective entry in its  lt dependencies gt  tag

User · Answer

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

User · Answer

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

[maven] Differences between dependencyManagement and dependencies in Maven

Examples related to maven

Examples related to pom.xml

Examples related to dependency-management