This is the second part in an introduction to Architecture Rules.

The first part, Architecture Rules 101 went over a short, sweet, and simple configuration.

Reminder

So remember, the basics of Architecture Rules is that it is

• Java.
• Open Source.
• Asserts architectural rules via unit tests.
• You write your rules in XML.
• Your run your tests with junit, ant, or a continuous integration server.

Source Locations

In this second installment of introductions to Architecture Rules, we’re going to go over source locations which enables the tool to support multi-module projects, and allows you to define when a particular source must exist, or may be optional.

By allowing a source to be optional, you can have different developers with different modules of code. So while one developer may have all eight modules of a project, another developer may only need to work on two or three of the modules.

Configuration

Here is an example that uses all of the current features supported by Architecture Rules 2.0.3.

<configuration>

<sources no-packages="exception">
<source not-found="exception">coretargetclasses</source>
<source not-found="ignore">webtargetclasses</source>
<source not-found="ignore">wstargetclasses</source>
</sources>

</configuration>

The first property that we see is the sources no-packages="exception". This tells Architecture Rule that, after reading all of the defined source directories, if no classes are found, then throw an Exception, more specifically, a NoPackagesFoundException. Here are the configuration options for no-packages:

The next interesting thing that we come across is <source not-found="ignore"> This configuration causes a SourceNotFoundException when the given path can not be found on the file system. This allows you to ensure that specific modules are present in the test. Alternatively, if you don’t particularly care if some source path is present, you can use the ignore value, which happens to be the default value. In the example above, the core module must be present for the tests to continue. The web and web services (ws) modules are optional.

So, after showing the simplistic configuration in Architecture Rules 101, we have now shown how you can customize your configuration to fit your needs with little work.

In the next Architecture Rules lesson, we’ll demonstrate how to get the Configuration and show how easy it is to provide programmatic configuration instead of or in addition to the XML configuration. Also coming up right after that, we’ll finally introduce the Maven 2 Architecture Rules plugin that Mykola has been working on for the past couple of months.

How about a short, sweet introduction to Architecture Rules.

The Basics

• Java.
• Open Source.
• Asserts architectural rules via unit tests.
• Write your rules in XML.
• Run your tests with junit, ant, or a continuous integration server.

Your Rules

You define your rules. For example, if you are developing n-tiered software, you probably have three layers. A DAO/integration layer, a service/business layer, and a presentation layer. Generally, the presentation layer does not interact directly with the integration layer. You could describe this rule as: com.company.project.presentation can not depend on the com.company.project.integration package. Its that easy.

The XML

The XML is in architecture-rules.xml and contains two section: <configuration> and <rules>. Configuration describes where your files are, and the rules simply describe a package, and one or more packages that it can not depend on.

<architecture>

<configuration>
<sources>
<source>targetclasses</source>
</sources>
</configuration>

<rules>

<rule id="dao">
<packages>
<package>
com.company.project.presentation
</package>
</packages>
<violations>
<violation>
com.company.project.integration
</violation>
</violations>
</rule>

</rules>

</architecture>

Thats it. You have a simple architecture-rules.xml.

The Unit Test

Just extend and run your tests.

public class SimpleArchitectureTest
extends AbstractArchitectureRulesConfigurationTest {

public String getConfigurationFileName() {
return "architecture-rules.xml";
}

public void testArchitecture() {
assertTrue(doTests());
}
}

More Features

In Architecture Rules 201, we’ll show you how to check for cycles (cyclic dependencies), write more action-packed rules, and describe how to handle source paths that can’t be found. We can also take a gander at the various Exceptions that can be thrown when rules are broken.

Go Get It

The next thing to do, is to go get it and try it out. Download, svn checkout, or put it in your pom.xml. Just add this repository:

<repository>
<id>architect-rules-repo</id>
<name>
architecture-rules hosted by code.google.com
</name>
<layout>default</layout>
<url>

http://architecturerules.googlecode.com/svn/maven2/

</url>
<releases>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<checksumPolicy>ignore</checksumPolicy>
</snapshots>
</repository>

And this dependency:

<dependency>
<groupId>com.seventytwomiles</groupId>
<artifactId>architecture-rules</artifactId>
<version>2.0.3</version>
</dependency>