Sonar is an “Open Source Quality Management Platform”. It provides software analysis using many great open source tools such as Checkstyle, PMD, Maven, and Cobertura to provide a dashboard with granular drill down capabilities from projects, to packages, to classes. Architecture Rules has been added to their public hosted instanced (they call this instance Nemo). I encourage you to check out Architecture Rules on Sonar. Sonar is also continuously building our project and running our tests with Hudson.

While investigating back links to our websites, I discovered an issue in Sonar’s issue tracker where they were discussing finding a tool that could analyze architecture so that they can add additional reporting to Sonar. This issue brought me to the source of the issue. I added my input to that issue. It turns out that they would prefer to utilize a project like ours more than the alternatives because our project is the most active. The alternatives have not been updated in years. Sonar also really wants to add DSM analysis reporting to their product, so they are looking for an architecture analysis tool to handle this.

We are discussing with the Sonar project team how we might fill this role.

OK, lets lay out a road map for 3.0. I sent this message to the architecture-rules-user mailing list and the architecture-rules-dev mailing list tonight. I have a few things that I want to see put into it, and I’d also like to hear what you want in it.

org.architecturerules

First. The big change is the groupId which is finally going to be moved to org.architecturerules for the core project and the maven plugin. I don’t have the domain yet. I have a fund raiser page where I was hoping to get about $30 to secure the domain for 3 years. So far no contributions : \ Maybe if any of your work for a company that uses the project, and the company has donated money in the past, you could ask your boss for a small $30 contribution to this project. Regardless, we’ll get it eventually and the project needs to get off of com.* and the maven plugin needs to be the same groupId.

architecture-rules-ant

We are going to refactor the ..architecturerules.ant package to its own jar so that:

• User’s who want to use the ant interface can include this jar.
• By including the jar, you get the Ant jars and dependencies. If you don’t use Ant, you don’t need the jar or the ant libraries.
• As we add new functionality to architecture rules someone else could take on the task of keeping the ant task up to date on their own schedule.
• This module also acts as an example of how to extend the core – add your own functionality!
• Allows us to develop new ant features and fix ant issues without doing a major release of the core. There are a couple of open ant-related issues in the issue list.

The downsides is that the API is broken, but we are willing to accept this given that this release the packages are all changing to org.architecturerules so the API will be broken anyway.

Issue 59: DependencyConstraintException should report the violating class

This is sort of a tough issue. We utilize jDepend which only looks at packages. However, Mykola brought Classycle to my attention (which I included on the alternatives page) which looks at class dependencies rather than package dependencies. We could move off of jDepend and switch over to using Classclye to find dependencies, or we could continue to use jDpend, and when a rule is broken, we can jump over to Classycle to figure out which class is breaking the rule. Another benefit to Classclye is that it is able to detect static dependencies which jDpend is not. I actually got an email from SonarJ, a commercial competitor listed on the alternatives page who congratulated us on developing a good open source architecture risk mitigating project but pointed out that jDepend could not detect static dependencies. I think in the long term we need to support detecting static dependencies so this Classycle might have been an important find.

Looking to get involved? We’re looking for contributors for this task. Welcome to the team, Raja.

Issue 60: XML reports

The only other current issue that I would like to tackle somehow is the output of the XML reports. I sent out a pretty detailed email on this to the user and dev mailing list. I got little response. I put a copy of the email in the issue which includes a prototype for the XML output. The premise would be that the execution of architecture rules results in the output of an XML file that describes all of the rules, the packages that were investigated because of that rule, the dependencies of each package that match that rule, and a list of each violation. One major change would be that instead of throwing an exception when a rule is broken, the rest of the packages would be investigated first and then the XML output is written, and then an exception could be thrown describing all of the rules that were broken – not just the first rule.

The reason for this XML output is two-fold: first, it provides output for other developers to start processing and developing new tools for which could be good for this project. second: it provides a data source for our maven 2 plugin to use to generate a site report for. Or this could be a new project: maven-architecture-rules-report-plugin. Either way, this is a good stepping stone to new functionality and growth for this project.

Looking to get involved? We’re looking for contributors for this task. Welcome to the team, Chris.

FindBugs

We added the FindBugs report recently to the maven-generated site. We should be able to clear this list for all of our code.

Remove 3rd party org packages

I had created an Issue to remove unnecessary dependencies to cut down on the number of libraries that we depended on. But I think this was implemented poorly to the point where it caused a reported bug. Also, we have a pseudo maven repository so that makes this issue almost moot.

This list encompasses most of the open issues in the issue tracker that I want to see implemented. There are a couple of issues that I am going to leave on hold (such as inverting the project to expect the user to define the accepted packages rather than the exceptional packages) and some that I can not fix with out money (continuous integration server).

All of these tasks are up for discussion. And most any of them are open to user contributions. If you are interested in taking on one of these tasks, just reply to this email, tell us what you want to work on, what questions you have, and maybe describe how you plan on implementing it. If its a small task, you can submit a patch, if its bigger, we can make you a contributor (for a short term or longer term depending on circumstances)

UPDATE: Issue 68: Listener Support

Adding support for event listeners gives us a few different things that we either need or that would benefit us in the future. This will hopefully invite other developers to begin extending the project. For example someone someday might make a GUI tool or an IDE plugin and want to provide real-time feedback to the GUI as packages are investigated. This also enables us to develop the XML report in a very modular fashion, without littering the services with code that is not related to performing the service that the class is named for. Listeners provide a great point for adding new functionality from too.

UPDATE: Introduce API Package

Interfaces will be moved to a new org.architecturerules.api package so that developers who wish to extend the project have someplace to start from. This will break backwards compatibility. But so will migrating to org.architecturerules, so if this is going to be done, it should be done now. Sorry everyone.

UPDATE: Issue 64: default-architecture-rules.xml

The initial state of the Configuration entity will be created by reading default-architecture-rules.xml. This essentially just allows us to define the default values via XML rather than defining them with java constants which is what we are doing now. This XML file is easier for the user to read to figure out the default values, is easy to add new default values to as we develop new features, and may be used to demonstrate a sample XML configuration or how features are configured.

UPDATE: Issue 67: Configuration Properties

The listeners require some configuration. Some other tools that have yet to be written may also require configuration. We’ll be adding support for arbitrary properties. These allow you to define a set of keys and a values that can be handed off to the Listeners and to other features that may be created in the future. This provides a pretty robust mechanism for providing configuration values for classes that extend the project.

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.