[hibernate-issues] [Hibernate-JIRA] Commented: (HBX-1110) Support for abstract/concrete pairs of POJO generation for hbm2java

[Jeff Walker (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HBX-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32439#action_32439 ] 

Jeff Walker commented on HBX-1110:
----------------------------------

Something todo: When generating the concrete part of the pair, check to see if the file exsists.  If it does, you probably don't want to generate the file.  It should be a property, but it kinda defeats the purpose of having the pair if the code generator will automatically overwrite both files.

> Support for abstract/concrete pairs of POJO generation for hbm2java
> -------------------------------------------------------------------
>
>                 Key: HBX-1110
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1110
>             Project: Hibernate Tools
>          Issue Type: Patch
>          Components: ant, hbm2java, reverse-engineer
>    Affects Versions: 3.2.4 Beta1
>         Environment: Hibernate 3.3.1GA, DB2 8.2, ant 1.6.5, Java 5.0 b11, eclipse (myEclipse blue 7.0) on windows xp sp3
>            Reporter: Jeff Walker
>            Priority: Minor
>         Attachments: HibernateExt.patch
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> I wanted hbm2java to be able to produce pairs of both abstract base classes and concrete classes for each POJO when reverse engineering.
> I altered the ant tasks to allow this syntax:
> <hbm2java ejb3="true" jdk5="true">
>     <base transform="{package-name}/base/{class-name}Base"/>
>     <concrete transform="{package-name}/{class-name}"/>
> </hbm2java> 
> I then extended the POJO exporter (used only when base or concrete are present).  This new exporter takes the meta model and runs once for all components, and then twice for each entity.  The first entity run is for the base classes.  Using the meta property overrides in the exporter, I force the class to be abstract, and change the generated class name according to the "transform" attribute.  I also save the name of the generated class name in a hash, mapped to the original name for use in the second phase.
> Then for the second run (still inside of the exporter), I force the generated class name (again via the "transform" attribute), and have the class extend the base class that was generated in the first phase.
> I also introduce two new variables into the template context: basePartOfPair and concretePartOfPair.  Set to true or false for the respective phase.  They default to false for when the regular exporter is used.
> In the templates I forced the properties to be protected (instead of private), and turned off the property generation for the concrete class.  I have code in the method (exportPersistentClass) to override these at meta properties, but that didn't work, as those properties need to be set on the property level, not the class level.
> You may refer to the following forum post for more background: http://forum.hibernate.org/viewtopic.php?t=994243
> Note that there is no test case for this functionality yet.  I'm not sure where to put it or what to do with that, but I will keep looking at that.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira