I try to keep an eye on what Internet users are saying about Architecture Rules. I checked del.icio.us for architecture rules. Its bookmarked by 60 people, which is pretty cool.

I read one description which concerned me. Chris suggested in his description that architecture rules as “way to ‘test architecture’, although it seems to be limited to detecting cyclic package dependencies”. Whoa, hold on. That’s not what we are about. Detecting cyclical dependencies is something that we can do, because we wrap JDepend, but the whole point of the project is to assert that the Rules that you have defined are not violated.

So, I tracked down Chris’s email address, which I found in his resume, which I found on his site. I emailed him.

I started by apologizing for the unsolicited email. Next I explained that I found his comment delicious, I reiterated his comment to him, then briefly explained and showed (with XML) how architecture rules was about asserting architecture through the definition of rules. I sent off the email assuming that Chris probably wouldn’t read it, and certainly wouldn’t respond favorably. Fortunately, I underestimated Chris.

Chris wrote back to me and thanked me for taking the time to write to him. He also pointed out that it is “always a good sign to me when an open-source project is interested in what people are saying about it.”

I just wanted to share this experience. I have no great analysis of it yet. I hope that it might encourage you to think about reaching out to your user base weather they be paying customers or users of your open source tool. After all, that’s why we write the code, right? To satisfy the end users, to make their jobs easier, or to change the way that people do business.

It is an open source project. That means our mishaps are out there for everyone to see.  Read about our major release that contained a major problem. Hopefully you can learn from our mistake (and we get some of those users back).

2.1.0 Release not so Good

Architecture Rules 2.1.0 was released this past weekend. It was going great. The project was getting a lot of attention on dzone, freshmeat.net drove some good traffic, it made the front page of The Server Side’s news section. All of these sites brought in a huge 128 downloads over the weekend while the previous version was out for seven months and only claims 222 downloads (by the way, I hope there are many times more users using the maven repository, which we don’t yet track for downloads). So it was a good weekend. And then it was pointed out that wildcards don’t work…

What Happened?

We implemented wildcards a few weeks ago and released a 2.1.0-SNAPSHOT for users to test out. Unfortunately, we don’t have a huge number of early adopters who are pulling down snapshots. So It seemed worked well and we planned a release for the weekend of July 4th. On June 29th, I got a friendly email from Andrew Swan. He had graciously taken the time to review the 2.1.0 code before the release. He discovered that the JPackage equals method delegated the work to the JPackage matches method. This broke the contract of the Java equals method because, in his words, “if a.equals(b), then b.equals(a) should also be true.” We all know that he is absolutely 100% correct. He even pointed me to Effective Java. We were excited to have Andrew reviewing the code and of course wanted to fix this problem. So we modified each reference to JPackge.equals to use JPackage.matches, ran our tests, and got a green “tests pass 82 of 82″.

I quickly followed that up by creating the binaries, committing everything to SVN, updating the documentation, and promoting the 2.1.0 release. However, one reference to .equals remained in the AbstractRuleService. This is the service that itterates over each package defined in each rule and checks to see if a given package is dependent on a package that it is not allowed to depend on. So now, if a package is defined using wildcards, it tries to match “com.company.application.*”, the String, to fully qualified String such as “java.util”. Of course, no package is ever going to be named with an asterisk character, so now if a package is defined with a wildcard, its not looked at. So wildcards are busted.

What Now?

Now, we released 2.1.1 just to fix this bug and pray that the 128 (and hopefully many many more though the maven repository) java developers who are rightfully concerned with mitigating architectural risk take some time to come back and grab the 2.1.1 release.

We have fixed the problem and quickly put up 2.1.1. Please download it, or update your pom.xml, give us another try, and Assert your Architecture.

Architecture Rules announces today that version 2.1.0 is released.

This was a fun release for two reasons: the new features, and the timing of the release.

Features

This was a major release in that it finally allows the users to define packages with wildcards. We’ve had a handful of users asking for this functionality for a while. We thank them for sticking with us despite having to ask us for this feature a few times. Read about how we implemented wildcards, how to use them, and some open issues with them on our previous post Wildcard Support.

We added method chaining to the domain classes to improve the feel of programmatic configuration. We talk about this change when we introduced the development goals for 2.1.0 and we talked in depth about method chaining when we started researching weather we should support it or not in our post Configuration Method Chaining.

We also made some positive changes to the project’s exceptions. We have a lot of exceptions for reporting different issues with architecture rules configuration and with the project that the tool is inspecting. We added some references to the packages that cause the exception to be thrown, and we tied all of the exceptions together under one higher level exception, the ArchitectureRulesException.

Release Date

Architecture Rules 2.1.0 is officially released on Friday, July 4th, 2008. This is a great date for a milestone release not because it is an American national holiday, but because it is one year from the day that development started on the project just about to the day. The first release, 1.0, was made just a couple weeks after development started, on July 17th, 2007. So happy anniversary Architecture Rules. With wildcards, a new domain name, and the upcoming maven 2 plugin, this next year is going to be bigger than the last.

Upcoming Releases

There will be a 3.0.0 release soon. Today, the maven 2 plugin that has been in development and the architecture rules project have different package names. One com.seventytwomiles and one info.manandbytes because I developed most of the core project as 72miles.com and Mykola developed the plugin under his domain mandandbytes.info. Before I can see developers using the plugin, we need to normalize the domain names. We’ll purchase ArchitectureRules.org any day now, update the site, update the documentation, and update the packages. This will be a major change to the users, warranting the 3.0.0 release. If you can afford a couple bucks to help get the domain, we would really appreciate the monetary support.

Once the packages are straightened out, we can push out the plugin. We need to write the documentation for the maven 2 architecture rules plugin. Mykola has been working hard on the plugin for months now. Its actually been ready for public consumption for a while, we just haven’t had the time to document it for the public. I will make this my next task and get the plugin out for everyone to start using. It makes Architecture Rules even easier to use by allowing the user to skip writing a silly little Test class and lets you move Architecture Rules right into your everyday build process. Awesome.

2.1.0

For a complete list of the changes, check out the 2.1.0 release/download page. You can get the update by downloading the new jar, or by updating your pom.xml to version 2.1.0.