On Dec 19, 2008, at 5:57 PM, Ignacio Coloma wrote:
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.
It is not a big issue. But some people using Gradle use 'Tests'. I
also ported one build to Gradle where there were Abstract test classes
called like 'GeneralTest'. The Ant junit runner tries to execute it
and throws an exception. So not relying on naming convention (only
offering them as additional filter) makes things more reliable.
- Hans
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
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
