Dependency Management and package architecture in Java programs

When using Maven you get a lot of reports out of the box. Version control reports, code quality reports, javadocs, etc.
This blog entry focuses on code quality reports, especially on the JDepend report and other ways of measuring and controlling code quality.

Why is dependency management so important?

This is a question that will arise sooner or later in almost every software project. Good dependency management is the key to maintainable software. In conjunction with well designed package architecture the dependency management will save lots of time and money when it comes to maintain and take care of a released software.
Maven enforces you to think about your project artifacts and dependencies before you start to implement your software. Because it follows the principle: One artifact per Maven project. Thus you are able to separate different tiers of your software into small artifacts which can be compiled, tested and released independently of the release of the full software system.
Think of a web enterprise application bundled in an EAR archive. The application usually consists of several artifacts:

• Foundation JAR archive(s)
• EJB JAR archive(s)
• Web application archive (WAR)

Every artifact can be tested independently from the others. Of course integration tests are often necessary to make sure the whole thing is still working. But it lets you concentrate on one point of your software system.
Things that must be avoided at any time are cyclic dependencies between those artifacts. For example, a method from an EJB JAR calls a method from a foundation JAR, and another method from the same foundation JAR calls an EJB JAR method. This would produce a cycle between the foundation tier and the EJB (Business Logic) tier. Maven is able to detect cycles and refuses to compile a project that contains cycles.
Even harder to detect are cycles between vertical slices in the same tier or cycles between logical layers of a physical artifact. Those cycles can be detected using JDepend. But JDepend is very limited and a System Architect is not able to define a logical architecture which can be controlled and oberved through the complete life of a software system. In this case you might want to consider the use of SonarJ or Sotograph. Why using a software to detect cycles? Because it is almost impossible for a human to see when a cycle creeps in!
Maven enforces you to keep an eye on your software design by providing a JDepend report out of the box. With JDepend you can control the couplings between packages and the stability or instability of particular packages or even cyclic dependencies between packages in your artifact.
If this is not enough for you and you would like to be able to define an architecture which can be controlled and observed by a Software Architect and/or the Software Developers have a closer look at the above mentioned SonarJ. It is recommend for middle-sized or big-sized software projects and can easily help you in maintaining and controlling your software design.
With SonarJ it is easily possible to declare allowed dependencies and directions between logical layers and vertical slices and to see when those dependencies or access directions are violated.