inSubpackage Matcher

[GoogleCodeExporter]

I can't figure out how to make these issues not show up as defects...  This is 
meant to be an 
enhancement.

It might be convenient to add an inSubpackage matcher to go along with the 
inPackage matcher in 
the Matchers class.  I think it would be pretty common to want to match all 
classes in a package and 
all of its subpackages without having to specify each one individually.  My use 
case was that I 
wanted to apply a MethodInterceptor to all of the classes in my project.

I've attached my implementation along with two TestNG test cases.  It does the 
matching using 
getName() and startsWith().  The whole thing's pretty simple, but it seems like 
it could be useful for 
a lot of people.  Take it or leave it.  :-)

Original issue reported on code.google.com by gk5...@gmail.com on 18 Mar 2007 at 9:21

Attachments:

• inSubpackage.txt

[GoogleCodeExporter]

Thanks. We'll get this into 1.1.

Original comment by crazybob...@gmail.com on 19 Mar 2007 at 2:23

• Added labels: 1.1

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 19 Mar 2007 at 7:33

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 19 Mar 2007 at 7:33

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by limpbizkit on 30 May 2008 at 6:55

• Added labels: Milestone-Release2.0
• Removed labels: 1.1

[GoogleCodeExporter]

Mike Ward wrote a patch that we've submitted. The fix was a bit more 
complicated in order to make sure that
   inSubpackage("com.go") 
doesn't match classes in com.google.inject, for example.

He also did due diligence on the package/classloader issues that come up for 
the java.lang.reflect.Package class. 
In particular, he made our inPackage matcher not respect classloaders, unlike 
our inPackage matcher.

Original comment by limpbizkit on 19 Jun 2008 at 11:28

• Changed state: Fixed