After some months evaluating Architecture Rules (AR for sort, web http://wiki.architecturerules.org/index.php?title=Main_Page) for serious use, and fiddling in a hate-love relationship with this tool (very good idea, not so well documented, some extrange behaviours that almost makes you resign), I found in their SVN and Maven repository that they have posted there the RC1 (release candidate) of the new 3.0.0 release.
For those that do not know about AR, this tool builds on top of JDepend to analyze the architecture, understood as module relationships and valid dependencies, of a Java project.
JDepend calculates OO metrics (Afferent, Efferent couplings, Instability, Abstractness, Distance) and also checks for circular dependencies between Java packages. JDepend is very fine, produces reports, has a fine GUI and there is an Eclipse plug-in available for your convenient use, but it is not easy to do validations in automated builds and continuous integration.
AR offers that. You can automate your architecture validation as an Ant task, Maven plug-in or, as it is most interesting to me, as a JUnit test case.
Thus, why this post? AR can be frustrating. You can easily get lost in dependencies, not found files and folders and different behaviours in unit tests if executed from Eclipse or from Maven. And this is why I would like to share some of my findings.
First, consider how to run it in an automated way. The Ant task or Maven plug-in have a disadvantage, they break the build if the architecture validation does not pass. It can be good for you but in my opinion I just want to know whether rules are being followed and continue with the rest of the build process, eventually running Sonar and publishing my results in Sonar dashboard.
3. Writing the test case.
To have this dependencies in your Maven repository, you need to add http://architecturerules.googlecode.com/svn/maven2/ as a repository. Using Artifactory as proxy/manager I was not able to get the artifact (401 error if I recall right) so I install the AR artifacts manually. For JDepend I found in the central Maven repo the version 2.9.1, not 2.9, but only 2.9 is downloadable from JDepend site, so I install it manually too. Look why I almost surrender?
Better don’t ask for transitive dependencies. They worked in past versions, even 3.0.0 snapshots, but not in RC1 (at least for me). That’s why I had to add these dependencies to POM.
Now lets create our rules file. First, don’t use the DTD, it did not work for me (Eclipse reports errors in it). The XML structure is easy enough for not being something that you MUST use.
<architecture> is the root node and inside it you will have one <configuration> and one <rules> elements.
Attribute not-found with value ignore is there to make the test not fail. But you keep the attribute no-packages with value exception in case no classes are found.
This rule means that classes from dummy.dataaccess package are not allowed to use classes from dummy.client and dummy.services packages. Nice, eh?
Finally, place the XML file in your test resources folder. Believe me, you don’t want to put it in another place: the classpath resolving mechanism is not the same when the unit test is executed inside Eclipse with JUnit and in Maven with Surefire. Maybe another planet conjunction, who nows?
If you have get to this point most probably I don’t need to explain that getConfigurationFileName() returns the name of the rule config file. You can add here absolute and relative paths, but as I mentioned before, the classpath resolving mechanism is not always working as you would like, and the worse do not work the same depending of the tool that run the test.
Finally, run the test. You will have it executed as any regular JUnit test case.
This is all for now. A very large post, now that I look at it, but a very interesting tool (and FOSS). Please contact me or post a comment on the blog if you would like to share your own findings and point of views about AR.
Hope I can add more useful information as I continue to work with AR.