> Unfortunately the problem I'm having isn't what you think it is. My demo
> class that references the "b" package is not in the "a" package, it's in the
> "a.child" package, so it should be found by "a.*" regardless of whether that
> pattern includes the "a" package.

> Unfortunately the problem I'm having isn't what you think it is. My demo
> class that references the "b" package is not in the "a" package, it's in the
> "a.child" package, so it should be found by "a.*" regardless of whether that
> pattern includes the "a" package.

> FWIW, I do think that "a.*" should include "a". I can't think of any
> scenario where that wouldn't be what the developer wanted, but maybe I just
> haven't thought about it enough. But let me reiterate that that's not
> related to the bug I'm reporting here.

> Cheers,

> Andrew

> On Tue, Jun 24, 2008 at 11:09 AM, Mike Nereson <mikenere...@gmail.com>
> wrote:

>> Thanks for checking that out.

>> The problem is that a.* is checking packages UNDER a. However, it is not
>> checking package a. That is to say, it will check a.b, but not a

>> So how do I address this... Should a.* match a? Should you have to
>> explicitly define a topmost level package? Is this going to be a problem
>> since java developers typically develop under a top level domain such as
>> com. net. org. ect?

>> I am not sure how to make a.* work. I don' think that a.* should include
>> a.

>> Ideas?

>> ~ Mike Nereson

>> On Mon, Jun 23, 2008 at 8:19 PM, Andrew Swan <andrew.i.s...@gmail.com>
>> wrote:

>>> Hi Mike,

>>> Thanks for all your hard work on this project.

>>> I managed to check out that snapshot from SVN and build it, and although
>>> wildcards seem to work in "violation" elements, they don't work for
>>> "package" elements. For example, I have a class that looks like this:

>>> package a.child;

>>> import b.B;

>>> public class Child {

>>>   private B bar;
>>> }

>>> I have this architecture rule:

>>>     <rule id="a-should-not-access-b">
>>>       <comment>Package "a" shouldn't use package "b"</comment>
>>>       <packages>
>>>         <package>a.*</package>
>>>       </packages>
>>>       <violations>
>>>         <violation>b</violation>
>>>       </violations>
>>>     </rule>

>>> I would expect this rule to fail, since my class in the "a.child" package
>>> depends on the "b" package, and the "a.child" package should have been
>>> detected by the "a.*" package wildcard. Changing the package pattern to
>>> "a..*" doesn't help. The rule only fails (correctly) when I explicitly
>>> declare the source package using "a.child". So this seems to indicate that
>>> wildcards aren't working in the "package" elements.

>>> Hope this helps,

>>> Andrew

>>> On Sun, Jun 22, 2008 at 6:56 AM, Mike Nereson <mikenere...@gmail.com>
>>> wrote:

>>>> Andrew, I finally got the wild card support in. You can use
>>>> 2.1.0-SNAPSHOT in the maven 2 repo to start using it now.

>>>> http://code.google.com/p/architecturerules/source/browse/maven2/com/s...

>>>> If you're using maven and our repo, just update your version to
>>>> 2.1.0-SNAPSHOT.

>>>> I'd appreciate if you could try it out and give me any feedback.

>>>> I have not updated the documentation and won't do so until we make the
>>>> release (any day now?) but I am going to write a blog post about it at
>>>> 72miles.com/blog where I write all my architecture rules posts.

>>>> The basics are: you can use wildcards in the packages or violations.

>>>> .* matches ONE package deeper.
>>>> ..* matches one or more packages deeper.

>>>> So that com.seventytwomiles.project.dao.*
>>>> matches com.seventytwomiles.project.dao.hibernate
>>>> matches com.seventytwomiles.project.dao.ldap
>>>> does not match com.seventytwomiles.project.dao.hibernate.user

>>>> but com.seventytwomiles.project.dao..*
>>>> matches com.seventytwomiles.project.dao.hibernate
>>>> matches com.seventytwomiles.project.dao.ldap
>>>> matches com.seventytwomiles.project.dao.hibernate.user

>>>> Also supports internal wildcards

>>>> com.seventytwomiles..*.filter.*
>>>> matches com.seventytwomiles.project1.web.filter.security
>>>> matches com.seventytwomiles.project1.web.filter
>>>> does not match com.seventytwomiles.project1.web.filter.security.wsbecause .* (..* would match this)

>>>> Get it?

>>>> So, you've got internal or terminating wildcards, and you have .* or ..*
>>>> for a single package or many packages.

>>>> Enjoy. Thanks for your patience. I'll let you know when I get the blog
>>>> post up with more examples and explainations.

>>>> 2.1.0 release will be this week sometime or next weekend maybe.

>>>> ~ Mike Nereson

>>>> On Wed, Jun 11, 2008 at 8:21 AM, Mike Nereson <mikenere...@gmail.com>
>>>> wrote:

>>>>> Andrew, and everyone, if you're up for it, can you help me to define
>>>>> the types of wild cards and then we can figure out what should be supported
>>>>> and what should not.

>>>>> Here is a list of what I have come up with:

>>>>> Terminating: com.company.*
>>>>> Starting: *.project.dao.UserDAO
>>>>> Middle: com.company.*.dao.UserDAO
>>>>> Class: com.company.project.dao.*DAO

>>>>> Are there more? Should the tool support them all? Does defining a
>>>>> violation using the class name  wildcard make the configuration more complex
>>>>> (harder to read and maintain?)

>>>>> I'd appreciate your feedback. Tell me whatever you're thinking on this.

>>>>> Thanks.

>>>>> ~ Mike Nereson

>>>>> On Wed, Jun 11, 2008 at 7:06 AM, Mike Nereson <mikenere...@gmail.com>
>>>>> wrote:

>>>>>> Hi Andrew. Its temporary. Hopefully up today or tomorrow. Sorry about
>>>>>> that.

>>>>>> No progress on the wild cards. I am back on my computer though, so I
>>>>>> will see if I can start them this weekend.

>>>>>> Thanks for hanging in there with us.

>>>>>> ~ Mike Nereson

>>>>>> On Wed, Jun 11, 2008 at 2:30 AM, Andrew Swan <andrew.i.s...@gmail.com>
>>>>>> wrote:

>>>>>>> Hi Mike,

>>>>>>> Just checking in to see how wildcards are going; I went to the web
>>>>>>> site but got a 404 error at this URL:

>>>>>>> http://www.72miles.com/architecturerules

>>>>>>> Is the site just down temporarily?

>>>>>>> Andrew

>>>>>>> On Thu, May 15, 2008 at 10:18 AM, Mike Nereson <
>>>>>>> mikenere...@gmail.com> wrote:

>>>>>>>> Andrew, I am glad to hear that. Mykola and I are the two developers
>>>>>>>> on Architecture Rules. He is working hard on the maven plugin. I would have
>>>>>>>> implemented the wild cards for you already if my main computer's motherboard
>>>>>>>> didn't crash about 2 months ago. As soon as I replace that part, I'll be
>>>>>>>> able to knock out that wild card support for you. I am really glad to hear
>>>>>>>> that you want to use it.

>>>>>>>> I really really appreciate the feedback. Once we get the wild cards
>>>>>>>> in, and you are using it, please don't hesitate to send us an update as to
>>>>>>>> how you are you using architecture rules, how well, or not well its working
>>>>>>>> for you, and any suggestions that you have to make it better.

>>>>>>>> Again, thanks.

>>>>>>>> ~ Mike

>>>>>>>> On Wed, May 14, 2008 at 7:46 PM, Andrew <andrew.i.s...@gmail.com>
>>>>>>>> wrote:

>>>>>>>>> As further feedback, I'll be applying this promising tool to our
>>>>>>>>> flagship application's codebase as soon as wildcards are available.
>>>>>>>>> Any idea when this might be? I appreciate you are probably working
>>>>>>>>> solo on this project in your spare time, so I don't want to hassle
>>>>>>>>> you
>>>>>>>>> too much.

>>>>>>>>> Cheers,

>>>>>>>>> Andrew

>>>>>>>>> On Apr 24, 5:01 am, "Mike Nereson" <mikenere...@gmail.com> wrote:
>>>>>>>>> > Sakke, I can't wait to finish implementing wild card support so
>>>>>>>>> that
>>>>>>>>> > you can test it for us ( :

>>>>>>>>> > Again, thanks for the feedback, for sticking with us, and for
>>>>>>>>> > reaffirming the need for wild card support.

>>>>>>>>> > --
>>>>>>>>> > ~ Mike Nereson

>>>>>>>>> > On Wed, Apr 23, 2008 at 2:57 PM, Sakke Wiik <
>>>>>>>>> sakke.w...@gmail.com> wrote:

>>>>>>>>> > >  I agree with Andrew. We're currently not using this tools
>>>>>>>>> because it's
>>>>>>>>> > >  too complex without package wildcards. More info in my
>>>>>>>>> previous post

>>>>>>>>> http://groups.google.com/group/architecture-rules-users/browse_frm/th.
>>>>>>>>> ..

>>>>>>>>> > >  cheers,
>>>>>>>>> > >  Sakke Wiik

>>>>>>>>> > >  On Apr 22, 4:12 pm, "Mike Nereson" <mikenere...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > >  > Thanks for the feedback, Andrew. I can appreciate your
>>>>>>>>> example.

>>>>>>>>> > >  > The whole reason for this project was to create a clean and
>>>>>>>>> simple,
>>>>>>>>> > >  > easy to read and easy to maintain interface to JDepend's
>>>>>>>>> ability to
>>>>>>>>> > >  > assert dependency rules. I think, based on your example,
>>>>>>>>> that we need
>>>>>>>>> > >  > to implement support for terminating wildcards for both
>>>>>>>>> packages and
>>>>>>>>> > >  > violations.

>>>>>>>>> > >  > --
>>>>>>>>> > >  > ~ Mike Nereson

>>>>>>>> --
>>>>>>>> ~ Mike Nereson