> 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