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.

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 If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off.

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 cuase 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 monatary support.

Once the packages are straigned 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.

This is a reprint of a fantasy authored by Yutaka Kachi and translated by Mikiko Kachi. Originally from http://www.catch.jp/openoffice/whats_oss/index_en.html.

I am reprinting it because it is only available through PDF. I want to share it and make it easier to read and comment on. I found it in 2005 and saved the PDF. I found the the file this morning and thought it would be good to share and discuss.

Long long time ago, there was a tree in a field of grass near a village. One day, this tree bore a lot of delicious fruit.

The fruit were very delicious. So villagers soon harvested all of the fruits.

There was no end to the number of people who cut branch of this tree and take them home.

Because of this, the tree died in a few years.

In the village, there was a clever merchant. He grafted the tree before the tree died.

And he fertilized the tree, cut off branch when it’s too much. He took care of the tree for a long time.

Then the tree bore fruit. He sold it and made big money.

He was a real worrier. He fenced around the tree and was always watching the tree.

This merchant was not just an worrier, but also a hard worker.
His effort made the fruit more delicious and a lot of people bought it.

Some people delivered it to busy villagers, and some people made jam from the fruits and sold it.

The merchant monopolized the fruit tree.

When someone said to him “ there are many worm holes ” , he heard nothing of it and said “ It’s cheap so you can’t complain that.”

When someone asked him “ do you use any harmful fertilizer?”
he said “ it’s company secret” and wouldn’t answer that question.

When someone offered him “ I’d like to buy branch”, he said “ I don’t want to have competitors” and rejected the offer.

More and more people started to sell the fruit and more and more people bought it.

Then the merchant increased the price and made a big profit.

In this village, there was a young man who really loved this fruit. When the merchant increased price of the fruit, he couldn’t afford it any more because he was very poor.

So, he got interested in another tree near the village. This tree also bore a lot of fruit, but its taste was not so good and no one had cared for it. The young man started taking care of it with his friends.

Therefore, the tree bore more fruit than they could eat. So they put up a sign board that said “ Free”. There were some people who take the fruit away although they didn’t take care of the tree, but the young man didn’t mind at all.

The young men kept making effort for years to improve taste of the fruit as much as possible. Some people who took the fruit said “ I will help you”, “I will help you too because we don’t want to kill this tree like the first one” and helped doing time-consuming works.

The more people helped, the more people took the fruit. When the fruit run short, the people grafted the tree to grow more. They put up “ Free” sign boards on new trees also.

Some people delivered the fruit, and some people made jam from the fruit. They were very cooperative and sometimes they pay for agricultural equipment, fertilizer and inviting specialists to get advise.

So they reduced warm holes, improved the taste of the fruit, and their fruit became much more popular.

Years later, many fruit trees were planted around the village and bore a lot of delicious fruit.

The villagers started delivering the young men’s fruit together to far-off town. In that town, many people said “I’ve never had such a delicious fruit !” and the fruit became popular. It sold like hot cakes.

And not only the young man but also his friends and villagers all became happy.

By the way, what happened to the merchant who monopolized the fruit tree?

His business was also going well. For only a short while he had a fewer customers, but he expanded his business by hiring many people, shipping the fruits to far-off town, buying up fruit trees which had grown in other villages, etc.

There was no difference between the young man and the merchant in terms of making delicious fruit.

This is a great, simple explanation of how open source works and why the model it is successful. Growing a fruit tree is relatively easy compared to writing software, but as software development tools get easier to use, and more people learn to write code, it was and is inevitable that the number of open source tools and the quality of those tools will increase.

There are two more PDFs that talk around open source licensing at http://www.catch.jp/openoffice/whats_oss/index_en.html.