i've always wanted to define the hamcrest matchers configuration in a clean java style instead of the (refactoring-unsafe!) XML file. so i came up with the following solution (see patch):

** class SampleHamcrestConfiguration implements HamcrestConfiguration { public static void main(String[] args) { new JavaGeneratorBuilder() .addConfigurations(new SampleHamcrestConfiguration()) .targetClass("com.foobar.SampleMatchers") .build() .generate(); } public Collection<Class<?>> matchers() { Collection<Class<?>> matcher = new LinkedList<Class<?>>(); matcher.add(MyMatcher.class); return matcher; } } **

what do you guys think? next step would be to allow a package scan, so new custom matchers will be picked up automatically ;)

~christoph

PS: forgot to mention that i've fixed a BUG concerning generating matchers by a given inner classes in ReflectiveFactoryReader:

javaMethod.getDeclaringClass().getName().replace("$", ".")

minor simplification and introduced a verbose flag for additional sysout output: ** public static void main(String[] args) { new JavaGenerator() .addConfigurations(new SampleHamcrestConfiguration()) .targetClass("com.foobar.SampleMatchers") .verbose(true) .generate(); } **

still thinking about whether to support multiple source directories. comes in handy if re-using other modules HamcrestConfiguration which are using different source dirs...

i just had a look at how to scan for classes within a package, so to get rid of maintaining a list of all custom matchers, and it works PERFECTLY (even with nested classes, didnt try anonymous classes though, but should be possible as well). to accomplish that i've "backported" a guava class (ClassPath). maybe it's a good idea to add a dependency to guava anyway as it became in the meanwhile kind-a standard library extension?!

** public static void main(String[] args) { new JavaGenerator() .addConfigurations(new ScanningHamcrestConfiguration("com.foobar")) .targetClass("com.foobar.SampleMatchers") .generate(); } **