Architecture Rules 102

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">core\target\classes</source>
<source not-found="ignore">web\target\classes</source>
<source not-found="ignore">ws\target\classes</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:

sources no-packages values
Value Description
exception causes a NoPackagesFoundException when zero classes are found among all of the defined sources
ignore default all test continue although there are no classes to test

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.

source not-found values
Value Description
exception causes a SourceNotFoundException when the path does not exist
ignore default all test continue although the classes at the given path will not be included in the test

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.