architecture rules 2.1.0 released

[Mike Nereson]

First, thanks to everyone who has stuck with this project so far. I have received input and feedback from every user on the mailing lists. Thanks for sticking with us this far, supporting this project, and giving the time to give back to the project through submitting issues, talking to us here on these lists, and talking through instant messengers.

Second, the reason for the email is to share that I released 2.1.0 of Architecture Rules tonight. It has been a long time since the last release and we have added some great new features, fixed some big issues, and made a few minor improvements to the API (hopefully without breaking any backwards compatibility.) You can checkout the release page for a complete list of changes. I've also added a blog post to introduce some of the new features, and to introduce the project to developers. The blog post also lays out a road map for the next release, which will probably be 3.0.0 given the changes that I'd like to see made.

2.1.0 release, download, and changes: http://72miles.com/architecturerules/releases/release-210
2.1.0 blog post: http://72miles.com/blog/posts/category/open-source/architecture-rules/
for maven2 users: http://72miles.com/architecturerules/maven-repository

The biggest new features is the support of wildcard package names. You can read how to add wildcards to your existing configurations or new configurations either in the documentation or on my blog post about wildcard support.

wildcard documentation: http://72miles.com/architecturerules/sample-configuration#wildcards
wildcard blog post: http://72miles.com/blog/posts/architecture-rules-wildcard-support/

Please upgrade to 2.1.0 and please take the time to report any issues or ask any questions that you may have at the user group architecture...@googlegroups.com.

Thanks everyone.

~ Mike Nereson
~ http://72miles.com/blog

[Mike Nereson]

Posted on dzone. If you want to help promote the project go vote it up : ) Thanks.

http://www.dzone.com/links/architecturerules210_released.html

~ Mike Nereson

[Mike Nereson]

Thanks to everyone who voted on dzone to help get to the front page.

Its now on dzone, the server side, freshmeat.net, and hopefuly even infoq.com eventually.

These front page stories are important to the growth of the project. Each time Architecture Rules makes front page dzone, we get hundreds of views and new users who download the jars. I can't track the maven repository usage, but I assume there are many more using the maven repo than downloading the jars directly.

Architecture Rules was featured at Openversion.com this past week. The author wrote some great words about the project about how it could be used and why it is important to use. My favorite part of the post is where the author suggested that "ArchitectureRules can become as popular as FindBugs or PMD". That would be awesome and wouldn't be possible without the help of all you who help publize the project. http://blog.openversion.com/project-highlight-architecture-rules/

So again, thanks for voting and helping to spread the word.

~ Mike Nereson

[Oliver Gierke]

Hey Mike,

I've just stumbled over architecture-rule on TSS and played around
with it on my way to work a little. It's refreshing to see a very
nicely programmed little brother of SonarJ. I can not remember when it
was such a fun to dive into the sources. I guess a lot of other OS
projekt could take a leaf of your book regarding code quality and
documentation. A few things and thoughts:

1. Would you mind if I create an XSD from the DTD? Most tools provide
more sophisticated support for working with XSD.

2. I've played around with wildcards a little and could not get it
work at all. To me it seems that line 278 in AbstractArchitectureRules
is the problem. You call layer.equals(javaPackage) which of course
hard compares both path string, which does not work for wildcarded
layers. Changing the line to layer.match(javaPackage) seems to result
in reasonable results for me.

3. Once I got the wildcarding working I've played around with your
syntax a little. You use double dots "..*" to embody multiple
packages. Wouldn't a double asterisk "**" be more speaking? E.g.
foo.bar.**.foobar.*. I know this syntax from Maven and other tools, so
I feel much more comfortable with it. I've tried replacing your RegEx
Transformation in JPackage.regExMatch(..) to replaceAll("\\\\.\\*\\*",
"\\\\.\\[A-Za-z_0-9.]*"), adapted the test cases and it seems to work

4. Another thing regarding wildcards is the following case. I want to
ensure that the package core and all subpackages do not have
dependencies to any other packages I'd like to specify the following:

package: foo.bar.core..*;
violation: foo.bar..*

Of course this fails, as the violation matches the package itself.
Could we check if the current package to be tested against the
violation matches the package first to prevent self violations?

Just tell me what you think about the suggestions. I also would not
hesitate to get my hands dirty if you need support.

Regards,
Ollie

On Jul 5, 4:59 pm, "Mike Nereson" <mikenere...@gmail.com> wrote:
> Thanks to everyone who voted on dzone to help get to the front page.
>
> Its now on dzone, the server side, freshmeat.net, and hopefuly even
> infoq.com eventually.
>
> These front page stories are important to the growth of the project. Each
> time Architecture Rules makes front page dzone, we get hundreds of views and
> new users who download the jars. I can't track the maven repository usage,
> but I assume there are many more using the maven repo than downloading the
> jars directly.
>
> Architecture Rules was featured at Openversion.com this past week. The
> author wrote some great words about the project about how it could be used
> and why it is important to use. My favorite part of the post is where the
> author suggested that "ArchitectureRules can become as popular as

> FindBugs<http://findbugs.sourceforge.net/>or
> PMD <http://pmd.sourceforge.net/>". That would be awesome and wouldn't be
> possible without the help of all you who help publize the project.http://blog.openversion.com/project-highlight-architecture-rules/

[Oliver Gierke]

One more time its me. There's another thing I've discovered. To me it
feels quite strange to define, what is forbidden instead of what is
allowed. The approach of defining violations generates a lot of false
positives if not defined correctly. I think it would be easier to do
not allow any dependency by default - generating false negatives - and
the step by step defining what is allowed and what not.

To my mind this much more fits into the natural process of
architecture definitions. There you don't define "subsystem X is not
allowed to communicate with Y, Z". Rather you define the allowed
dependencies. Furthermore adding a package to the project
automatically makes it accessible to all other packages by default. So
I'd have to define the new package at possibly all minus one rules to
be invalid.

Of course you would need to allow common allowed dependencies (like
java.lang.util) that are transparently added to all rules, as you
would have to define them on every rule otherwise.

Hope you are not overwhelmed with critique. I just see the
potential ;). And would like to help, if you like.

Regards,
Ollie

On Jul 5, 4:59 pm, "Mike Nereson" <mikenere...@gmail.com> wrote:

> Thanks to everyone who voted on dzone to help get to the front page.
>
> Its now on dzone, the server side, freshmeat.net, and hopefuly even
> infoq.com eventually.
>
> These front page stories are important to the growth of the project. Each
> time Architecture Rules makes front page dzone, we get hundreds of views and
> new users who download the jars. I can't track the maven repository usage,
> but I assume there are many more using the maven repo than downloading the
> jars directly.
>
> Architecture Rules was featured at Openversion.com this past week. The
> author wrote some great words about the project about how it could be used
> and why it is important to use. My favorite part of the post is where the
> author suggested that "ArchitectureRules can become as popular as

> FindBugs<http://findbugs.sourceforge.net/>or
> PMD <http://pmd.sourceforge.net/>". That would be awesome and wouldn't be
> possible without the help of all you who help publize the project.http://blog.openversion.com/project-highlight-architecture-rules/

[Mike Nereson]

Hi Oliver. I am not ignoring you. I was up late last night, got up late this morning and didn't have time to respond to all of the Architecture Rules emails, and now I am at my day job, where I try not to send too many architecture rules emails.

I really appreciate the input and I know for a fact that the project will only get better if people like you provide feedback. So thanks a ton.

I will review these emails again tonight or tomorrow and share my thoughts with you.

I just see the potential ;). And would like to help, if you like.

I would love to have your help. Lets talk again later.


~ Mike Nereson

[Oliver Gierke]

Hi Mike,

didn't want to offend you not replying. It's just that all that stuff
came to my mind while playing around with it. =) As I was incited by
the tool, I just kicked things off and implemented the "positive" list
configuration model. If you like, I could send you that stuff zipped
up to take a glance at it.

Regards,
Ollie

[Mike Nereson]

Does it change architecture rules so that it only supports positives? Or does it now support both?

Can you create an issue on the issue tracker, describe how you think it ought to work, then attach the patches?

http://code.google.com/p/architecturerules/issues/list

I am really looking forward to looking at it and glad to see that you were interested in this project enough that you added some new code ( :

~ Mike Nereson