Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

• 

  Mike 9:36 pm on August 3, 2008 Permalink | Reply
  Tags: Architecture-Rules (13), Road-Map   

  Architecture Rules 3.0 Roadmap 

  UPDATE Aug-30-2008

  • added API package
  • added Listeners
  • added Configuration Properties
  • added default-architecture-rules.xml

  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

  I want to refactor the ..architecturerules.ant package to its own jar so that:

  • User’s who want to use the ant interface and 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 project.
  • 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 I think that is OK given in the 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.
  

  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.

  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 unneccessary 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.

  Maven 2 Plugin SNAPSHOT

  And while I have your attention, Mykola has released a 0.0-SNAPSHOT of the maven 2 plugin. Has anyone tried it yet? Anyone want to try it out?

  Thanks everyone.

  http://72miles.com/architecturerules (and someday architecturerules.org)

   

  Reply Click here to cancel reply.

  Name (required)

  Email (required)

  Web Site

  Notify me of followup comments via e-mail

   
• 

  Mike 10:32 pm on July 10, 2008 Permalink | Reply
  Tags: Architecture-Rules (13)   

  architecture rules on delicious 

  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, thats 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.

  Mike, and Jamo are discussing. Toggle Comments

   
  • 

    Jamo 8:05 am on July 17, 2008 Permalink

    Wow, I’m glad you didn’t catch me talking bad about your project on some obscure forum somewhere!! I’ll be sure to call it arkitexture rools to avoid discovery!

  • 

    Mike 10:12 am on July 17, 2008 Permalink

    @Jamo – I think if you are talking bad about the project you have already discarded it and are not going to use it. I would not try to convince you otherwise with an email.

    This particular prospective user, however, just didn’t realize the full potential of the project so I went out on a limb and sent him a targeted email. Hopefully we got a new user.

• 

  Mike 9:37 pm on July 10, 2008 Permalink | Reply
  Tags: Add new tag, Architecture-Rules (13)   

  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.

   
• 

  Mike 10:44 pm on July 4, 2008 Permalink | Reply
  Tags: Architecture-Rules (13)   

  architecture-rules-2.1.0 released 

  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.

   
• 

  Mike 5:54 pm on June 26, 2008 Permalink | Reply
  Tags: 2.1.0, Architecture-Rules (13), wildcard   

  If You’re Feelin’ like a Pimp go on Brush your Asterisk* Off 

  Architecture Rules is proud to announce that it now support wild cards.

  Benefits of Wildcards

  Wildcards bring the ability to match multiple packages with one Rule entry. This falls inline with the original goal of the project, which was to simplify the usage of jDepend and to define rules in a way that is very readable, understandable, and modifiable.

  With wildcards, users can now define a package or violation in one line with the ability to match many packages. This means you won’t need to update your Rules each time you add a new package and your XML configuration file will be much shorter.

  Wildcard Patterns

  We identified a few different Wildcard Patterns. Some we don’t support and don’t plan on supporting, others we do support, and there are still a couple that we want to add.

  Here is a description of what we now support:

  Internal Wildcard	Terminating Wildcard
  Wildcard stated within a package.	Wildcard stated at the end of a package.
  com.company.*.dao	com.company.project.dao.*
  Match One Package	Match Many Packages
  Match to the depth of one package with the .* combination	Match to the depth of one or more packages with the ..* combination
  com.company.*.dao matches only com.company.SOMETHING.dao	com.company.project.dao..* matches ..dao.hibernate as well as packages below hibernate: ..dao.hibernate.user, ..dao.hibernate.account, etc.

  Example

  Now creating a rule to assert that the web layer does not interact with the DAO (or integration) layer is as easy as:

  <rule id="web-layer">
   <comment>web and dao mix like oil and water</comment>
   <packages>
    <package>com.company.app.web..*</package>
   </packages>
   <violations>
    <violation>com.company.app.dao..*</violation>
   </violations>
  </rule>
  

  Prior to wildcards, you might have needed to define ..web.controllers, ..web.filters, ..web.views, ..web.forms, ..web.tags as the packages, and then you would have had to defined every ..dao package as a violation. Now its easy!

  Implementation

  Architecture Rules uses Regular Expressions to compare the packages with wildcards against the inspected packages. The regular expression needed to be able to handle exact packages, one package deep, and one or more packages deep. We accomplished this by modifying the given package with wildcards (such as com.company.project.*) to apply regular expression characters.

  Thank you to Ryan Stewart for helping us hash out this expression. This is what we came up with:

  final String regex = this.path
      // foo.bar exactly foo.bar
      .replaceAll("\\.", "\\\\.")
      // foo.bar.1 or foo.bar.1.2 and so on...
      .replaceAll("\\\\.\\\\.\\\\*", "\\\\.\\[A-Za-z_0-9.]")
      // packages only
      .replaceAll("\\.\\*", "\\.[A-Za-z_0-9]*");
  

  The break down is this: The third line of code looks for ..* combination and replaces it with the regular expression to allow for any string with any number of periods.

  The fourth line of code looks for the remaining .* combinations and replaces it the an expression to match package name but no more periods.

  If you consider yourself a regular expression wizard, please consider taking a moment to review this and offer any feedback or suggestions that you might come up with. Thank you.

  Outstanding Issues

  One usability issue that we have uncovered is the matching of the package prior to the wildcard. For example, some users think that com.company.project.* should match com.company.project in addition to the packages under project. Others aren’t sure it should match ..project. As of right now ..project is not included as a match. We are open to comments on this and welcome feedback from the early adopters.

  Roll Out

  Wildcard support has been slated for the 2.1.0 release which should happen any day now. We are just waiting for a couple of our early adopters to test the wildcards with the 2.1.0-SNAPSHOT that is currently in the maven repository.

  If you’ve been waiting and can’t wait to try it out, or if you can help out with testing, just grab the jar, or add our repository and dependency to your maven pom.xml.

  Thanks

  Finally. Thanks you to Andrew Swan for hounding us to get this feature implemented and for sticking with us while we worked on it. Also thank you for testing it for us. Thank you, again, to Ryan Stewart for helping out with the regular expression. And as always, thank you to Mykola Nickishov for working diligently on the Maven 2 plugin that will be released with the 2.1.0 release of Architecture Rules.

  And thank you to you for reading this far. Now go get Architecture Rules and start Asserting Your Architecture!

  architecture-rules-2.1.0 released | 72 Miles is discussing. Toggle Comments

   
• 

  Mike 7:52 am on June 5, 2008 Permalink | Reply  

  Architecture Rules 102 

  This is the second part in an introduction to Architecture Rules.

  The first part, Architecture Rules 101 went over a short, sweet, and simple configuration.

  Reminder

  So remember, the basics of Architecture Rules is that it is
  

  • Java.
  • Open Source.
  • Asserts architectural rules via unit tests.
  • You write your rules in XML.
  • Your run your tests with junit, ant, or a continuous integration server.

  Source Locations

  In this second installment of introductions to Architecture Rules, we’re going to go over source locations which enables the tool to support multi module projects, and allows you to define when a particular source must exist, or may be optional.

  By allowing a source to be optional, you can have different developers with different modules of code. So while one developer may have all eight modules of a project, another developer may only need to work on two or three of the modules.

  Configuration

  Here is an example that uses all of the current features supported by Architecture Rules 2.0.3.

  <configuration>
  
  <sources no-packages="exception">
  <source not-found="exception">core\target\classes</source>
  <source not-found="ignore">web\target\classes</source>
  <source not-found="ignore">ws\target\classes</source>
  </sources>
  
  </configuration>
  

  The first property that we see is the sources no-packages="exception". This tells Architecture Rule that, after reading all of the defined source directories, if no classes are found, then throw an Exception, more specifically, a NoPackagesFoundException. Here are the configuration options for no-packages:

  sources no-packages values

  Value	Description
  exception	causes a NoPackagesFoundException when zero classes are found among all of the defined sources
  ignore	default all test continue although there are no classes to test

  The next interesting thing that we come across is <source not-found="ignore"> This configuration causes a SourceNotFoundException when the given path can not be found on the file system. This allows you to ensure that specific modules are present in the test. Alternatively, if you don’t particularly care if some source path is present, you can use the ignore value, which happens to be the default value. In the example above, the core module must be present for the tests to continue. The web and web services (ws) modules are optional.

  source not-found values

  Value	Description
  exception	causes a SourceNotFoundException when the path does not exist
  ignore	default all test continue although the classes at the given path will not be included in the test

  So, after showing the simplistic configuration in Architecture Rules 101, we have now shown how you can customize your configuration to fit your needs with little work.

  In the next Architecture Rules lesson, we’ll demonstrate how to get the Configuration and show how easy it is to provide programmatic configuration instead of or in addition to the XML configuration. Also coming up right after that, we’ll finally introduce the Maven 2 Architecture Rules plugin that Mykola has been working on for the past couple of months.