Menu
If you have Project A and it needs all the dependencies of Project B, do you declare Project B a parent of Project A, using inheritance, or a dependency of project A? They seem to have the same effect.
911
A dependency is libraries you need to get your code to compile. This can be your own code, or libraries such as Apache Commons. A parent contains information, but nothing to actually build, that is shared between a number of your projects.
What is Maven Dependency? In Maven, a dependency is just another archive—JAR, ZIP, and so on—which our current project needs in order to compile, build, test, and/or run. These project dependencies are collectively specified in the pom. xml file, inside of a <dependencies> tag.
Now child POM need to refer the parent POM using parent tag and specifying groupId/artifactId/version attributes. This pom file will inherit all properties and dependencies from parent POM and additionally can include extra sub-project specific dependencies as well.
How does maven locate and resolve dependencies? Unlike other repository formats (APT, YUM Rubygems, there is no main index file that enumerates all possible artifacts available for that repository. Maven uses the coordinates values for a given dependency to construct a URL according to the maven repository layout.
The two approaches are different, one is inheritance, and the other one is a simple dependency.
By dependency you'll only have the binary transitive dependencies of the project B.
By using as a parent project you'll inherit the configurations like plugins, building model, repositories, dependency-management, dependencies and so on, it depends on the case.
My rule of thumb is for scm configuration, project configuration, and development or company standards, I use a parent project (inheritance).
106
I'd say if Project B is intended to act as a "universal parent" or somesuch - that is, a starting point for many projects with identical dependencies (or with the same starting point for their dependencies) then go right ahead and make B the parent.
Otherwise, if it's actually more of a "handy thing to have" - for example it's got utility/core type methods that a lot of projects will find useful, but don't rely upon for their very existence, then it's logically a dependency.
You might even consider splitting Project B into two along those lines. That's what I've done in the past:
mygroup-parent is a project that consists solely of a POM file with dependencies that I want every single project to get - enforcing a standard approach. For example, I've got TestNG and Mockito in there.
mygroup-core is a fully-fledged Java project that has handy things that get used a lot, but are not a must. I've got helper methods for things specific to my site, and dependencies like Apache HttpClient and Google Guava.
9
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
