wildcards

[Mike Nereson]

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?

--
~ Mike Nereson

[Andrew]

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

[Mike Nereson]

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

[Sakke Wiik]

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/thread/c16e975cd5131dc9


cheers,
Sakke Wiik

[Mike Nereson]

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

[Andrew]

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

[Mike Nereson]

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

--
~ Mike Nereson

[Andrew Swan]

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

[Mike Nereson]

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

[Mike Nereson]

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

[Mike Nereson]

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/seventytwomiles/architecture-rules/

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.


~ Mike Nereson

[Andrew Swan]

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

[Mike Nereson]

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

[Andrew Swan]

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

[Mike Nereson]

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

[Oliver Gierke]

Hi Mike,

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>

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

> ...
>
> read more »