db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-621) Add javax.jdo.JDOEnhancerMain to call the enhancer via standard API
Date Fri, 12 Dec 2008 17:56:44 GMT

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

View raw message