> Whether it is called "Enhancer" or JDOEnhancerMain I really don't care since a user will invoke via a plugin or Ant task etc.
I originally called it JDOEnhancerMain to distinguish it from the name of the interface. But javax.jdo.Enhancer is fine since it doesn't conflict.
> It would be nice to support wlidcards and subdirectories search:
I agree. So you could have javax.jdo.Enhancer -s /home/clr/myproject/target/classes
and all of the classes in the target/classes dir would be enhanced using metadata from the target/classes directory.
Would you also support javax.jdo.Enhancer -s /home/clr/myproject/target/classes/com/myproject
as well? Then the enhancer would only enhance the classes beginning with com.myproject. But the output directory -d option would still put the classes in the "right place" based on the complete class name.
> All options should have shortform and longform, so "-pu" and "-persistenceUnit" should be valid (just as "-v"/"-verbose" will be)
I agree. How about setSearchSubdirectories(boolean flag).
> > Also, javax.jdo.Enhancer should send all the arguments, including unknown arguments to the implementation.
> How is it to do that ? The JDOEnhancerMain/Enhancer will be looking for an implementation of JDOEnhancer in the classpath via the services registry. When it finds one it creates an instance and makes use of the JDOEnhancer API. This API defines what features are supported.
We have always supported extension points for the JDO API and I don't think this should be an exception.
I can see how to support flags that are passed as a single element of the args array; that is, they don't take arguments. These could be collected and passed as Ilan suggests as a String[ ] of hints. I don't see how to pass flags with arguments, since the argument would be treated as a file or class name.
I'd propose that any hints would be ignored if not recognized, just as we do in other parts of the spec.
> Another issue, which JDOEnhancer implementation will be used when more than one implementation is found?
The way it works now is that it takes the first implementation that it finds.
We can add a property to the persistence.xml to specify the implementation, similar to the way the PMF is specified in jdoconfig.xml. And could we use something in jdoconfig.xml?
If you like, propose something different.