Architecture Rules is proud to announce that it now support wild cards.

Benefits of Wildcards

Wildcards bring the ability to match multiple packages with one Rule entry. This falls inline with the original goal of the project, which was to simplify the usage of jDepend and to define rules in a way that is very readable, understandable, and modifiable.

With wildcards, users can now define a package or violation in one line with the ability to match many packages. This means you won’t need to update your Rules each time you add a new package and your XML configuration file will be much shorter.

Wildcard Patterns

We identified a few different Wildcard Patterns. Some we don’t support and don’t plan on supporting, others we do support, and there are still a couple that we want to add.

Here is a description of what we now support:

Example

Now creating a rule to assert that the web layer does not interact with the DAO (or integration) layer is as easy as:

<rule id="web-layer">
 <comment>web and dao mix like oil and water</comment>
 <packages>
  <package>com.company.app.web..*</package>
 </packages>
 <violations>
  <violation>com.company.app.dao..*</violation>
 </violations>
</rule>    

Prior to wildcards, you might have needed to define ..web.controllers, ..web.filters, ..web.views, ..web.forms, ..web.tags as the packages, and then you would have had to defined every ..dao package as a violation. Now its easy!

Implementation

Architecture Rules uses Regular Expressions to compare the packages with wildcards against the inspected packages. The regular expression needed to be able to handle exact packages, one package deep, and one or more packages deep. We accomplished this by modifying the given package with wildcards (such as com.company.project.*) to apply regular expression characters.

Thank you to Ryan Stewart for helping us hash out this expression. This is what we came up with:

final String regex = this.path
    // foo.bar exactly foo.bar
    .replaceAll("\\.", "\\\\.")
    // foo.bar.1 or foo.bar.1.2 and so on...
    .replaceAll("\\\\.\\\\.\\\\*", "\\\\.\\[A-Za-z_0-9.]")
    // packages only
    .replaceAll("\\.\\*", "\\.[A-Za-z_0-9]*");       

The break down is this: The third line of code looks for ..* combination and replaces it with the regular expression to allow for any string with any number of periods.

The fourth line of code looks for the remaining .* combinations and replaces it the an expression to match package name but no more periods.

If you consider yourself a regular expression wizard, please consider taking a moment to review this and offer any feedback or suggestions that you might come up with. Thank you.

Outstanding Issues

One usability issue that we have uncovered is the matching of the package prior to the wildcard. For example, some users think that com.company.project.* should match com.company.project in addition to the packages under project. Others aren’t sure it should match ..project. As of right now ..project is not included as a match. We are open to comments on this and welcome feedback from the early adopters.

Roll Out

Wildcard support has been slated for the 2.1.0 release which should happen any day now. We are just waiting for a couple of our early adopters to test the wildcards with the 2.1.0-SNAPSHOT that is currently in the maven repository.

If you’ve been waiting and can’t wait to try it out, or if you can help out with testing, just grab the jar, or add our repository and dependency to your maven pom.xml.

Thanks

Finally. Thanks you to Andrew Swan for hounding us to get this feature implemented and for sticking with us while we worked on it. Also thank you for testing it for us. Thank you, again, to Ryan Stewart for helping out with the regular expression. And as always, thank you to Mykola Nickishov for working diligently on the Maven 2 plugin that will be released with the 2.1.0 release of Architecture Rules.

And thank you to you for reading this far. Now go get Architecture Rules and start Asserting Your Architecture!