hibernate tools and the destination package

I've had alot of challenges getting hibernate tools to generate my pojos in 2 separate processing steps. Some teams may generate the POJOS directly with annotations using hibernate tools but I have found that to allow me to make modifications to the POJOs and control various aspects of pojo generation that is not currently supported by the tools or requires changing the template (which is not hard to do) is difficult. For example, if you generate a pojo directly from the JDBC configuration, then you cannot specify an "extends" class unless you change the template.

I have found that generating the pojo through a two-step process gives me the control I need without resorting to changing the template. Here is the process I used.

• Step 1: Create a reveng.xml file for the application. Use this reveng.xml file for Step 2.


• Step 2: Create HBM files using a dedicated hibernate console and a dedicated code generation configuration. Use the reveng.xml file from Step 1.


• Step 3: Modify the HBM files as appropriate. For example, adding a meta tag to indicate the superclass of my entity. If I generate the HBM files again they will be overwritten and your changes lost unless you use Eclipse's local history mechanism to merge the previous version into the new version or use version control systems. Note that I generally create POJOs without annotations as it allows me to touch only the XML files and make other changes that I find easier in the HBM files. This is a specific choice I made for my application.


• Step 4: Generate the POJO using a dedicated hibernate console and a dedicated code generation configuration. The hibernate console for this step should have "reverse from JDBC connection" turned off and mappings specified in the configuration. The mappings should be those created in Step 2. In this case, since no reverse engineering is going on and the HBM files are the only source of information for the domain objects, hibernate tools will generate POJOs from the HBM files.

I often have problems generating the properly class and output destination combination for my POJOs. You have a few choices for specifying the package and the output destination. Generally, I modify the HBM files with a package specification as an attribute in the hibernate-mapping xml tag. Using this, the HBM will generate a POJO with the proper package specification. When doing it this way, you need to specify the top of the source directory as the output as in eclipse, the pojo java source file will then be inserted in the proper file hierarchy based on the package name.

One other way that I have not tested fully is to specify a fully qualified class name in the reverse engineering XML specification. This will create the class name with the right package and when generating the HBM file, it will be placed in the package as specified in the reveng specification. When doing this, it looks like the package specification in the reverse JDBC connection portion of the code generation configuration is ignored. Specifying the FQN in the reveng file seems to be the most direct way to have the package carry through and generate pojos directly. However, it may not be the most flexible for your build scenario.

I have never had the package specification honored in way that I could recognize for generating either pojos or hbm files when using reverse engineering from the JDBC connection for code generation.

Since HBM files are xml files, one could conceivable use an Ant talk to modify the HBM XML to automatically change the package or add other clever meta tags. I'll investigate this approach later.