I have been reading for a while about an explicit versus transitive (implicit) dependency declaration in Maven. Most of the people tend to agree that you should always explicitly declare the libraries that your project depends on, mostly to avoid versions mismatch.

That is perfectly reasonable, but how should we tackle our internal dependencies? I see absolutely no reason to keep the explicit dependency between the modules, if they can be resolved via transitive mechanism.

My use case scenario:

• my team develops software in major.minor.micro release cycles, ex: 1.1.1, 1.1.2, 1.3.0, etc...
• with each release we increment the versioning scheme for all of our modules in the project (so A:1.0, B:1.0 become A:1.1, B:1.1)
• we are using reactor projects, nested as far as two levels deep

My gut is telling me - get rid of the dependency spaghetti. Anyone will prove me wrong? Reactor (dependencies) graphs are more than welcome :-)

An example:

My parent project uses following modules (external dependencies omitted):

Project:1.1   
 - core:1.1
 - +-- util:1.1 
 -   +-- xml-helper:1.1
 - logic:1.1
 - +-- util:1.1 
 -   +-- xml-helper:1.1
 - gui:1.1

The question is: should I declare xml-helper:1.1 as a dependency in core's and logic's pom.xml? That dependency will be automatically resolved (transitive) as I'm using util module.

If I declare it, I get a larger pom to maintain.

If I skip it, I might get into troubles when dependencies evolve over time.