Architecture Rules 3.0.0 goes RC1

Old post from Dec 11th, 2009

———————-

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.

So I finally decided to go for the JUnit test case. I can give you details on running in Ant and Maven but in this post from now on I will focus on JUnit and I will split the rest of the contents in these areas:

1. Dependencies.

2. Configuration.

3. Writing the test case.

4. Running.

1. Dependencies.

You need to add some dependencies to your project in Eclipse and Maven POM (I did not use m2eclipse for this). In Eclipse build path you have to add architecture-rules-3.0.0-rc1.jar. In Maven POM you will need to add, with test scope:

GroupId ArtifactId Version
 org.architecturerules  architecture-rules  3.0.0-rc1
 commons-digester  commons-digester  1.8
 commons-io  commons-io  1.4
 jdepend  jdepend  2.9

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.

2. Configuration.

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.

Inside <configuration> you place where are your classes and whether to check for cyclical dependencies. You can add attributes to make the test fail if classes are not found. For example:

        <sources no-packages="exception">
            <source not-found="exception">bin</source>
        </sources>
        <cyclicalDependency test="true"/>

If you, due to some planet conjunction as it was my case, use different binary folders inside Eclipse and in Maven, that will not work and you will need to add something like:

        <sources no-packages="exception">
            <source not-found="ignore">bin</source>
            <source not-found="ignore">maven/bin</source>
        </sources>
        <cyclicalDependency test="true"/>

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.

Inside <rules> you place your, emmm, rules. Each rule will define a source package and what packages can not depend this on. For example:

        <rule id="dao-isolation">
            <comment>DAO should not access business and client layers</comment>
            <packages>
                <package>dummy.dataaccess</package>
            </packages>
            <violations>
                <violation>dummy.client</violation>
                <violation>dummy.services</violation>
            </violations>
        </rule>

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?

3. Writing the test case.

Now, lets write the test case. It is very simple, just a simple class extending org.architecturerules.AbstractArchitectureRulesConfigurationTest with two methods: getConfigurationFileName() and testArchitecture(). Their contents are simple:

package dummy.test;
import org.architecturerules.AbstractArchitectureRulesConfigurationTest;
public class ArchitectureRulesTestCase extends AbstractArchitectureRulesConfigurationTest {
    public String getConfigurationFileName() {
        return "rules-definition.xml";
    }
    public void testArchitecture() {
        assertTrue(doTests());
    }
}

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.

4. Running.

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.

Cheers!

Author: deors

senior technology architect in accenture, with a passion for technology related stuff, celtic music and the best sci-fi, among other thousand things!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s