I just created this issue. I'd like to hash it out here before we make the decision as to what we are going to do with this one...
A few users over the past many months have mentioned the desire to support wild cards. I have known that this is the direction that we need to head in.
I suppose we need to determine where exactly we should support wild cards, and where we should not.
We have the packages definitions, and the violation definitions as part of declaring a Rule. I think the violations should support wildcards for sure. I am not sure, however, if we should support wildcards when declaring the packages. I am thinking about me as a reader of the XML file. It would be rather difficult to read, and understand if I am not very familiar with the project's structure, and the XML is full of wildcards. Also, on the implementation side, I think adding wildcards to checking violations will be really, while adding regex to the packages being checked would be a lot dirtier.
I'd really like to hear your thoughts. Have you been waiting for wildcards? Would you use them in the packages and violations?
For a package structure of real-world depth, this tool isn't usable
unless the "package" element supports wildcards. Without wildcards,
you have to declare every single package like this:
<packages>
<package>foo.domain</package>
<package>foo.domain.person</package>
<package>foo.domain.person.impl</package>
<package>foo.domain.account</package>
<package>foo.domain.account.impl</package>
<package>foo.domain.order</package>
<package>foo.domain.order.impl</package>
<package>foo.domain.lineitem</package>
<package>foo.domain.lineitem.impl</package>
<!-- repeat ad nauseam for every domain type, could be hundreds -->
</packages>
Not only is this verbose, it's also very fragile; if any sub-packages
in the "domain" hierarchy are added/moved/deleted/renamed, I have to
remember to update architecture-rules.xml, and my IDE is certainly not
going to do this for me (e.g. when doing a "Move" refactoring).
I can't see any down side (from the user's POV) to allowing package
wildcards. If anyone has a weird package structure that doesn't lend
itself to wildcards (which would be unusual), they can simply choose
not to use them.
Andrew
On Apr 18, 1:04 pm, "Mike Nereson" <mikenere...@gmail.com> wrote:
> I just created this issue. I'd like to hash it out here before we make
> the decision as to what we are going to do with this one...
> A few users over the past many months have mentioned the desire to
> support wild cards. I have known that this is the direction that we
> need to head in.
> I suppose we need to determine where exactly we should support wild
> cards, and where we should not.
> We have the packages definitions, and the violation definitions as
> part of declaring a Rule. I think the violations should support
> wildcards for sure. I am not sure, however, if we should support
> wildcards when declaring the packages. I am thinking about me as a
> reader of the XML file. It would be rather difficult to read, and
> understand if I am not very familiar with the project's structure, and
> the XML is full of wildcards. Also, on the implementation side, I
> think adding wildcards to checking violations will be really, while
> adding regex to the packages being checked would be a lot dirtier.
> I'd really like to hear your thoughts. Have you been waiting for
> wildcards? Would you use them in the packages and violations?
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.
> 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.
> 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.
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:
> > 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.
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.
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
> > > 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.
> 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
>> > > 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.
> 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
>>> > > 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.
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.
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.
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:
>> 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
>>>> > > 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.
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.ws because .* (..* 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.
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.
> 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:
>>> 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
>>>>> > > 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.
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.
> 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
> 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.ws because > .* (..* 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.
>> 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:
>>>> 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
>>>>>> > > 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.
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:
> 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:
> 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.
>> 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
>> 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.
>>> 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:
>>>>> 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
>>>>>>> > > 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.
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:
> 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:
>> 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.
>>> 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
>>> 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.
>>>> 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:
>>>>>> 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
>>>>>>>> > > 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.
> 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.
Try the new snapshot. I think it might fix this problem
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.
I have not figured out how to address this yet. So a.* still will not detect a. I'll think about this this weekend.
Thanks for your patience, Andrew.
~ Mike Nereson
On Tue, Jun 24, 2008 at 3:40 AM, Andrew Swan <andrew.i.s...@gmail.com> wrote:
> 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:
>>> 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.
>>>> 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
>>>> 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.
>>>>> 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:
>>>>>>> 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
>>>>>>>>> > > 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
sorry, I seem to have not seen this thread when posting my wildcard
pattern suggestions <a href="http://groups.google.com/group/ architecture-rules-users/t/f3029b8e5016b084">here</a>
the thing is that tools I have worked with before (SonarJ e.g.) define
the patterns on the type level as it actually is a wildcarded fully
qualified class name. So a.* would match all types in package a. One
of your posts above implies that you have thought about defining
patterns this way.
Currently I think simply a* would match package a PLUS direct
subpackages, wouldn't it?
Regards,
OIllie
On Jun 26, 2:43 pm, "Mike Nereson" <mikenere...@gmail.com> wrote:
> > 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.
> Try the new snapshot. I think it might fix this problem
> 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.
> I have not figured out how to address this yet. So a.* still will not detect
> a. I'll think about this this weekend.
> Thanks for your patience, Andrew.
> ~ Mike Nereson
> On Tue, Jun 24, 2008 at 3:40 AM, Andrew Swan <andrew.i.s...@gmail.com>
> wrote:
> > Hi Mike,
> > 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:
> >>> 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.
> >>>> 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
> >>>> 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:
> >>>>> 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:
> >>>>>>> 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
|
