Declare as dependency or as parent

Question

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.

Answer 1

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).

Answer 2

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.