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.

Architecture Rules has been progressing. After 5 releases under 2.0.x, we have a tentative road map for the next release, slated to to hold the 2.1.0 tag. Here are some of the upcoming features you can look for.

Maven Plugin

Mykola has been working hard on the maven-architecture-rules-plugin. With it, you will no longer even need to write a unit test. Just write your architecture-rules.xml, and attach the appropriate goal to Maven’s test phase. He has been tackling multi project projects recently. This is sure to make asserting your architecture even easier for Maven users.

Maven repository

Speaking of Maven users, development of Architecture Rules relies on Maven. Today, to use Architecture Rules, you’d have to download the Architecture Rules jar and put it on your own repository, or your lib directory. This is too much work and we shouldn’t expect you to have to do that. We are going to get the jars and sources up into a Google Code hosted repository so you can just declare the dependency and repository in your pom.xml and get started even faster. In fact, we already have it up, its just not documented yet. Here is the first public mention of it.

Just add this repository:

<repository>
<id>architect-rules-repo</id>
<name>architecture-rules repository</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:

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

Java 5

We think its pretty safe to assume our users are up to Java 5 now, so we are going to update the code base to Java 5. This also makes it easier for us to integrate the maven-architecture-rules-plugin. If you are not up to Java 5, the greatest version you will be able to use is 2.0.3, which is a good release and should do the trick for you.

Configuration Chaining

Finally, rather trivial in the whole scheme of things, but if you opted to use the programmatic configuration over the recommended XML configuration, then we’re going to slightly modify the Configuration class to allow for chaining. So instead of:

Configuration configuration = new Configuration();
configuration.addRule(rule1);
configuration.addRule(rule2);
configuration.addRule(rule3);

You can use:

Configuration configuration = new Configuration()
.addRule(rule1)
.addRule(rule2)
.addRule(rule3);

This is going to be great once you see an example where you add all of your rules, add all the package locations, and set up the other options.

So thats what we have been working on at Architecture Rules