proposal for new JavaGenerator replacing the XML configuration file

[GoogleCodeExporter]

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

Original issue reported on code.google.com by christop...@gmail.com on 6 Apr 2014 at 2:30

Attachments:

• 2014_04_06-hamcrest_java_config_proposal-christoph_pickl.patch

[GoogleCodeExporter]

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

javaMethod.getDeclaringClass().getName().__replace("$", ".")__

Original comment by christop...@gmail.com on 6 Apr 2014 at 2:33

[GoogleCodeExporter]

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...

Original comment by christop...@gmail.com on 8 Apr 2014 at 5:19

Attachments:

• 2014_04_08-hamcrest_java_config_proposal-christoph_pickl.patch

[GoogleCodeExporter]

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();
  }
**

Original comment by christop...@gmail.com on 11 Apr 2014 at 6:12