I'm generating mapping files with hbm2hbmxml. I'd like to generate hibernate mappings with default-access="field". Is there a way to do this similar to using a custom reverse strategy? I can see from the source that the template system uses a HibernateMappingGlobalSettings class to get these settings. Is there a way to provide one of these to hbm2hbmxml?

Thanks for your help.

I read more of the hibernate tools docs. Could I use a custom exporter rather than hbm2hbmxml? I



'm thinking I would subclass HibernateMappingExporter, then set the correct setting in the HibernateMappingGlobalSettings that it contains. So,



Sound right?

I went ahead and created the custom exporter as previously described. Here it is:



Here is my build target:



I get the following exception when I try to run the target:



Any help would be appreciated. Thanks.

I'm trying a different avenue now. I"m trying to modify the templates to always add the default-access="field" attribute to the <hibernate-mapping> tag when I generate the hbm.xml files.

I have read all the docs and looked at the source code, but I still do not understand the semantics of the <hbmtemplate> attributes.

I'm trying to create an equivalient to:



However, I don't understand the sematics of templateprefix, or template (or filepattern really). I have a customized version of hibernate-mapping.hbm.ftl and I want to use that. Do I need all the templates or can I just use this one? How do I specify it's path within my source? Do I need to duplicate the templates folder in the Hibernate-Tools src folder?

Do I only need to specify the updated template (it is not the base template for the generation).

So, I'm not sure where to go. This is what I have;


but it creates the following errors when run;



Thank you for any help you can give.

I have finally figured this out. This solution would have also worked for generating the Abstract domain classes (another post). This turns out to be pretty easy. I used a simple customized template to do this without writing any java code. It is a real shame that the documentation for Hibernate-Tools does not have more explicit information on how to use custom templates. It could really use some _well explained_ examples. It took me a long time to figure this out and it was a very simple piece of information that was needed to figure this out - the semantics of the templatepath attribute of the hibernate-mapping tab. So here is what I found.

Generation of the artifacts in Hibernate-Tools (java, hbm.xml, cfg.xml, etc.) happens through a template system. By customizing the templates, you can change the resulting artifacts that are generated. The current Hibernate-Tools uses the freemarker template system. You can read the freemarker docs, but I found that simply by looking at the templates, I could figure out how to modify them. If you download the Hibernate-Tools source, it will contain the templates. Relative to the root of the project folder, the path to the templates is "./tools/src/templates/".

The structure of the templates folder looks like this

templates/dao - templates for generating daos via <hbm2dao/>
templates/doc - templates for generating documentation
templates/dot - templates for generating ...
templates/hbm - templates for generating mapping files via <hbm2hbmxml/>
templates/lint - not sure
templates/pojo - templates for generating java via <hbm2java/>

The two most important points when using customized templates for artifact generation are;
1. The ant tools task must specify the root of the templates path using the templatepath attribute of the <hibernatetool> tag. So, the path you specify would potentially have the /dao, /doc, /dot, etc. folders within it. For example, my project folder structure looks like this;

project/src - my source
project/src/templates - my templates folder
project/src/templates/hbm - my mapping file templates
project/src/templates/hbm/hibernate-mapping.hbm.ftl - this is the one template file I customized.

So, my ant tools task definition uses a templatespath attribute like this;



Note that the path starts at the project root and leads to the folder containing the template subfolders.

2. Your customized template(s) must have the same name as the original template and must be in the same relative path as the original. You only need to provide the templates that you have customized. In otherwords, don't bother to copy all the templates from the Hibernate-Tools source to your own templates folder and then customize a few. You just need the ones that you will customize. When the Hibernate-Tools tasks (<hbm2java/>, <hbm2hbmxml/>, etc.) run, they will first look in the folder specified by the templatepath attribute for the template and if it is not found, they will get the standard one from the Hibernate-Tools.jar.

In my case, I was generating hibernate mapping files from the database using <hbm2hbmxml/> I simply wanted to make my hibernate mapping files using the default-access="field" attribute in the <hibernate-mapping/> tag, to force hibernate to use direct field access rather than getter/setter access. The first thing I had to do was identify the template that was used to generate the hbm.xml file. I looked for likely suspects in the templates/hbm folder. I found templates/hbm/hibernate-mapping.hbm.ftl. It looks like this:



Mine looks like this:



I added this section:



This is added in the section that inserts various kinds of non-default values. This checks to see if there is already a default-access value set. If so, I honor it. If not, I force default-access to "field".

The other place is this:




Basically, is just adds the default-access-"field" to the tag when no other non-default values exist.

With this in place and my templatepath correctly set so Hibernate-Tools can find it, may regular old <hbm2hbmxml/> task now generates my own custom mapping files.

For completeness, here is my full hibernatetools task in my ant build.xml file:

sorry for jumping in late. Looks like you got it all covered ? Otherwise let me know ;)

I wanted to do the same for hbm2java and ended with HBX-1132.