12:54 p.m.
[
http://opensource.atlassian.com/projects/hibernate/browse/HBX-1110?page=c...
]
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....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira