JarCastingDependency Management Metrics Maven Plugin
Maven plugin that computes the Dependency Management Metrics for your multi-module Java projects.
Dependency Management Metrics
The Dependency Management Metrics are defined by Robert C.Martin in his Clean Architecture book.
The metrics are consisted from two principles:
- Stable Dependencies Principle
- Stable Abstractions Principle
If you are already familiar with the theory part, feel free to skip to Getting Started part.
In the text below, the granularity of the term component is the same as a module in the Java ecosystem.
Stable Dependencies Principle
Any component that we expect to be volatile, should not be depended on by a component that's difficult to change. Otherwise, the volatile component will also be difficult to change.
A component that is designed to be very easy to change can be made very difficult by simply hanging a dependency to it from another component that's very difficult to change.
Stable/Unstable Components
What actually makes a component difficult to change(a.k.a Stable Component)? Many factors may make a software component difficult to change, i.e. its size, complexity, clarity, number of components that depend on it... For this situation only the last case is important. A component with lots of incoming dependencies is very hard to changes. Therefore these components are called Stable Components:
On the contrary, the following image shows the Component 1 which is a very Unstable Component, because Component 1 is depended on two different components and yet no other components are depended on it:
Stability Metrics
We can define the Stability Metrics by defining the Instability of a component: 
Now that we defined the metrics, we can define the actual principle of the Stable Dependencies:
A component should always be dependent of a more stable component
The first image shows an example where the principle holds.
The following image is an example of a clear violation of the principle:
where we can see that the Stable Component is dependent of an unstable Unstable Component 3.
Stable Abstractions Principle
Abstract Components
Abstract component is a component that holds only interfaces or abstract classes. These abstract components are very stable and ideal for less stable components to depend on.
Abstraction Metrics
We can define the level of Abstraction of a single component as follows: 
Now we can define the Stable Abstractions Principle which states:
A component should always be dependent of a more abstract component
Main Sequence
Now that we have defined the two principles, we can define the relationship between the Stability (I) and Abstractness (A): 
If we draw a line between the (0, 1) and (1, 0) points, we get a line that's called the Main Sequence line: 
This line is representing where all components should be.
Now we can define the place on that plot where components should not be, i.e. Zones of Exclusions:
Zone of Pain
Highly stable and concrete components. Not desirable because they are rigid. It cannot be extended because it's not abstract and it's very difficult to change because of its stability.
Zone of Uselessness
Highly abstract components without any dependents, i.e. useless components.
A component that sits on the Main Sequence is neither too abstract nor is too unstable.
Distance from Main Sequence
How far away is a component from the Main Sequence: 
Any component that has a D metric value that's not near zero can be reexamined and restructured.
Statistical analysis of a design is also possible by calculating the mean and variance of all the D metrics for the components within a design. A conforming design should have mean and variance values that are close to zero.
Getting Started
This plugin calculates and outputs the metrics stated and explained above for each component within a design:
- Stability metric
- Abstraction metric
- Distance from Main Sequence
The plugin also outputs the components present in the Zone of Pain and the Zone of Uselessness (if there are any) in the Zones of Exclusions section.
And finally the plugin can potentially break the build if any of the following principles are broken:
- Stable Dependencies Principle
- Stable Abstractions Principle
Add this to your parent pom.xml file:
<plugin>
<groupId>com.github.ignatij</groupId>
<artifactId>dependency-management-metrics-maven-plugin</artifactId>
<version>1.0.17</version>
<inherited>false</inherited>
</plugin>
If you want to potentially fail the build if any of the principles are violated add the configuration tag the following:
<plugin>
<groupId>com.github.ignatij</groupId>
<artifactId>dependency-management-metrics-maven-plugin</artifactId>
<version>1.0.17</version>
<configuration>
<failOnViolation>true</failOnViolation>
</configuration>
<inherited>false</inherited>
</plugin>
You can also customize the output file:
...
<configuration>
<output.file>...</output.file>
</configuration>
...
Feel free to report any issues or open a Pull Request for further improvements.