architecture-rules 2.1.1
It is an open source project. That means our failures are out there for everyone to see. Read about our major release that contained a major problem. Hopefully 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 Happend?
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 a 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.