[hibernate-issues] [Hibernate-JIRA] Updated: (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:all-tabpanel ]

Jeff Walker updated HBX-1110:
-----------------------------

    Attachment: tools.patch

Patch that supersedes the previous patch.  I took an approach that is closer to what Max wanted originally.

Adds a "generate-concrete" property to the hbm2java task.
If it is false, an abstract base class is made for the pojo.  It is expected to be used with a second hbm2java task, with "generate-concrete" set to true.  That will build the same pojos, but the concrete version that extends the abstract one.  If the "generate-concrete" property isn't present (either true or false), the regular code generation goes on as it did before the patch.

To facilitate all of this, another property was added to hbm2java, "overwrite".  When false, if the file  exists, it won't be overwritten and the file is skipped.  When true, the original file is replaced with the newly generated one.  The idea is to have the abstract class regenerated always, and the concrete only generated once.  The concrete version can be take user additions and allow the user to reverse engineer without loosing all of the changes made.  Only the full constructor would need to be done.

Also two properties were added to the hibernatetool task.  "abstract.base.transform" and "abstract.concrete.transform" control the package and classnames of the base and concrete classes, respectively.  These are needed at the top, so that the concrete exporter can know what the name of the abstract base is called, so that it can "extend" it.  If these two properties are not defined, code generation goes as it did before this patch.

Here is an example of my ant file:
<hibernatetool destdir="gen-src">
			<classpath>
				<path location="reveng" />
			</classpath>
			<jdbcconfiguration
				packagename="navy.selbd.model.gen" 
				detectmanytomany="false"
				configurationfile="hibernate.cfg.xml"
				reversestrategy="navy.selbd.hibernate.Selboard9ReverseEngineeringStrategy" />

			<property key="abstract.base.transform" value="{package-name}/base/{class-name}Base"/>
			<property key="abstract.concrete.transform" value="{package-name}/{class-name}"/>
			<hbm2java jdk5="true" ejb3="true">
				<property key="overwrite" value="true"/> <!-- defaults to true -->
				<property key="generate-concrete" value="false" />
			</hbm2java>
			<hbm2java jdk5="true" ejb3="true">
				<property key="overwrite" value="false"/> <!-- defaults to true -->
				<property key="generate-concrete" value="true" />
			</hbm2java>
		</hibernatetool>

I am flexible on all naming conventions.  I am asking for any comments or criticism to improve this and to speed up acceptance of my contribution.

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