Spring also includes a mechanism very easy to use and the dependency is not
very big (spring-core).
ClassPathScanningCandidateComponentProvider provider = new
ClassPathScanningCandidateComponentProvider(false);
provider.addIncludeFilter(new
AssignableTypeFilter(TestCase.class));
provider.addExcludeFilter(new NotInstantiableTypeFilter());
provider.findCandidateComponents(pakageName);
For example.
Anyway, is this really an issue? I don't know of a single case of a Test
class not ending with *Test.class.
On Fri, Dec 19, 2008 at 5:45 PM, Tom Eyckmans <[email protected]> wrote:
> Found a bug in this library:
> http://code.google.com/p/reflections/issues/detail?id=7
>
> fix is easy only treat .class files :P
>
> With this library we can also determine the test library that is used
> automatically if people use the annotations :)
>
> 2008/12/12 Adam Murdoch <[email protected]>
>
>>
>>
>> Hans Dockter wrote:
>>
>>> Hi,
>>>
>>> Peter Niederwieser just pointed out an interesting new library to me:
>>>
>>> http://code.google.com/p/reflections/
>>>
>>> It allows for scanning classpath and doing queries like:
>>>
>>> * get all subtypes of some type
>>> * get all types annotated with some annotation
>>> * get all types annotated with some annotation, including annotation
>>> parameters matching
>>> * get all methods annotated with some
>>>
>>> This sounds like a perfect tool for checking out which classes to execute
>>> as tests (for Junit 3.8/4.x and TestNG). That would be a much nicer
>>> mechanism than using excludes/includes (of course we would still offer
>>> includes/excludes for customization).
>>>
>>>
>> Or for discovering the plugins and tasks included in a bundle.
>>
>>
>> Adam
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
