Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
architecture-rules-users
Home
+ new post
About this group
Join this group
Message from discussion wildcards
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post will appear after it is approved by moderators
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Andrew  
View profile  
 More options Apr 22 2008, 1:49 am
From: Andrew <andrew.i.s...@gmail.com>
Date: Mon, 21 Apr 2008 22:49:49 -0700 (PDT)
Local: Tues, Apr 22 2008 1:49 am
Subject: Re: wildcards
Print | View thread | Show original | Report this message | Find messages by this author
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?

> --
> ~ Mike Nereson


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google