[
https://issues.apache.org/jira/browse/JDO-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656082#action_12656082
]
Craig Russell commented on JDO-621:
-----------------------------------
> 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.
> Add javax.jdo.JDOEnhancerMain to call the enhancer via standard API
> -------------------------------------------------------------------
>
> Key: JDO-621
> URL: https://issues.apache.org/jira/browse/JDO-621
> Project: JDO
> Issue Type: New Feature
> Components: api2
> Affects Versions: JDO 2 maintenance release 2
> Reporter: Craig Russell
> Fix For: JDO 2 maintenance release 3
>
>
> The proposed new class will use the standard enhancer API to enhance classes.
> The command line parameters would be similar to the original proposal of
> JDO-591, with changes as needed to use the new class in the TCK.
> java -cp classpath {enhancer-class} [options] [jdo-files] [class-files]
> where options can be
> -persistenceUnit persistence-unit-name : Name of a "persistence-unit"
> to enhance the classes for
> -d target-dir-name : Write the enhanced classes to the specified
> directory
> -checkonly : Just check the classes for enhancement status
> -v : verbose output
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
