Hibernate Tools

JBoss Tools 2.x includes Hibernate Tools and thus nothing is required besides downloading and installing JBoss Tools. If you need to update to a newer version of the Hibernate Tools just follow the instructions in the Eclipse IDE section.

To install into any Eclipse 3.3.x based Eclipse IDE you can either download the Hibernate Tools distribution from the Hibernate website or use the JBoss Tools update site (see also http://tools.hibernate.org for links to the update site).

If you download the Hibernate Tools distribution you need to place the /plugins and /feature directory into your eclipse directory or eclipse extensions directory. Sometimes Eclipse does not automatically detect new plugins and thus the tools will not be activated. To ensure eclipse sees these changes run eclipse with the -clean option. E.g. eclipse -clean Using the updatesite does not require any additional steps.

To use the tools via Ant you need the hibernate-tools.jar and associated libraries. The libraries are included in the distribution from the Hibernate website and the Eclipse updatesite. The libraries are located in the eclipse plugins directory at /plugins/org.hibernate.eclipse.x.x.x/lib/tools/. These libraries are 100% independent from the eclipse platform. How to use these via ant tasks are described in the Ant chapter.

The meta model is the model used by Hibernate Core to perform its object relational mapping. The model includes information about tables, columns, classes, properties, components, values, collections etc. The API is in org.hibernate.mapping and its main entry point is the Configuration class, the same class that is used to build a session factory.

The model represented by the Configuration class can be build in many ways. The following list the currently supported ones in Hibernate Tools.

In most projects you will normally use only one of the Core, Annotation or JPA configuration and possibly the JDBC configuration if you are using the reverse engineering facilities of Hibernate Tools. The important thing to note is that no matter which Hibnerate Configuration type you are using Hibernate Tools supports them.

The following drawing illustrates the core concepts:

Figure 2.1. Hibernate Core Concepts

The code generation is done based on the Configuration model no matter which type of configuration have been used to create the meta model, and thus the code generation is independent on the source of the meta model and represented via Exporters.

Code generation is done in so called Exporters. An Exporter is handed a Hibernate Meta Model represented as a Configuration instance and it is then the job of the exporter to generate a set of code artifacts.

The tools provides a default set of Exporter's which can be used in both Ant and the Eclipse UI. Documentation for these Exporters is in the Ant and Eclipse sections.

Users can provide their own customer Exporter's, either by custom classes implementing the Exporter interface or simply be providing custom templates. This is documented at Section 4.4.7, “Generic Hibernate metamodel exporter (<hbmtemplate>)”

The following features are available in the Hibernate Tools Eclipse plugins:

Mapping Editor: An editor for Hibernate XML mapping files, supporting auto-completion and syntax highlighting. It also supports semantic auto-completion for class names and property/field names, making it much more versatile than a normal XML editor.

Hibernate Console: The console is a new perspective in Eclipse. It provides an overview of your Hibernate Console configurations, were you also can get an interactive view of your persistent classes and their relationships. The console allows you to execute HQL queries against your database and browse the result directly in Eclipse.

Configuration Wizards and Code generation: A set of wizards are provided with the Hibernate Eclipse tools; you can use a wizard to quickly generate common Hibernate configuration (cfg.xml) files, and from these you can code generate a series of various artifacts, there is even support for completely reverse engineer an existing database schema and use the code generation to generate POJO source files and Hibernate mapping files.

Eclipse JDT integration: Hibernate Tools integrates into the Java code completion and build support of Java in Eclipse. This gives you codecompletion of HQL inside Java code plus Hibernate Tools will add problem markers if your queries are not valid against the console configuration associated with the project.

Please note that these tools do not try to hide any functionality of Hibernate. The tools make working with Hibernate easier, but you are still encouraged/required to read the documentation for Hibernate to fully utilize Hibernate Tools and especially Hibernate it self.

To be able to reverse engineer, prototype queries, and of course to simply use Hibernate Core a hibernate.properties or hibernate.cfg.xml file is needed. The Hibernate Tools provide a wizard for generating the hibernate.cfg.xml file if you do not already have such file.

Start the wizard by clicking New Wizard (Ctrl+N), select the Hibernate/Hibernate Configuration file (cfg.xml) wizard and press Next . After selecting the wanted location for the hibernate.cfg.xml file, you will see the following page:

Figure 3.1. Hibernate Configuration File Wizard

Enter your configuration information in this dialog. Details about the configuration options can be found in Hibernate reference documentation.

Press Finish to create the configuration file, after optionally creating a Console onfiguration, the hibernate.cfg.xml will be automatically opened in an editor. The last option Create Console Configuration is enabled by default and when enabled i will automatically use the hibernate.cfg.xml for the basis of a Console Configuration.

A Console Configuration describes to the Hibernate plugin how it should configure Hibernate and what configuration files, including which classpath is needed to load the POJO's, JDBC drivers etc. It is required to make usage of query prototyping, reverse engineering and code generation. You can have multiple named console configurations. Normally you would just need one per project, but more is definitly possible.

You create a console configuration by running the Console Configuration wizard, shown in the following screenshot. The same wizard will also be used if you are coming from the hibernate.cfg.xml wizard and had enabled Create Console Configuration .

Figure 3.2.  Creating Hibernate Console Configuration

The dialog consists of three tabs, General for the basic/required settings, Classpath for classpath and Mappings for additional mappings. The two latter ones is normally not required if you specify a project and it has /hibernate.cfg.xml or /META-INF/persistence.xml in its project classpath.

The following table describes the available settings. The wizard can automatically detect default values for most of these if you started the Wizard with the relevant java project or resource selected

Figure 3.3. Specifying Classpath in Hibernate Console Configuration

Figure 3.4. Specifying additional Mappings in Hibernate Console Configuration

Clicking Finish creates the configuration and shows it in the Hibernate Configurations view

Figure 3.5. Console Overview

A "click-and-generate" reverse engineering and code generation facility is available. This facility allows you to generate a range of artifacts based on database or an already existing Hibernate configuration, be that mapping files or annotated classes. Some of these are POJO Java source file, Hibernate *.hbm.xml, hibernate.cfg.xml generation and schema documentation.

To start working with this process, start the Hibernate Code Generation which is available in the toolbar via the Hibernate icon or via the Run > Hibernate Code Generation menu item.

3.4.1. Code Generation Launcher

When you click on Hibernate Code Generation... the standard Eclipse launcher dialog will appear. In this dialog you can create, edit and delete named Hibernate code generation "launchers".

Figure 3.6. Getting Hibernate Code Generation Wizard

Figure 3.7. Hibernate Code Generation Wizard

The first time you create a code generation launcher you should give it a meaningfull name, otherwise the default prefix New_Generation will be used.

Note

The "At least one exporter option must be selected" is just a warning stating that for this launch to work you need to select an exporter on the Exporter tab. When an exporter has been selected the warning will disappear.

The dialog also have the standard tabs Refresh and Common that can be used to configure which directories should be automatically refreshed and various general settings launchers, such as saving them in a project for sharing the launcher within a team.

On the Main tab you see the following fields:

Table 3.4. Code generation "Main" tab fields

Field	Description
Console Configuration	The name of the console configuration which should be used when code generating.
Output directory	Path to a directory into where all output will be written by default. Be aware that existing files will be overwritten, so be sure to specify the correct directory.
Reverse engineer from JDBC Connection	If enabled the tools will reverse engineer the database available via the connection information in the selected Hibernate Console Configuration and generate code based on the database schema. If not enabled the code generation will just be based on the mappings already specified in the Hibernate Console configuration.
Package	The package name here is used as the default package name for any entities found when reverse engineering.
reveng.xml	Path to a reveng.xml file. A reveng.xml file allows you to control certain aspects of the reverse engineering. e.g. how jdbc types are mapped to hibernate types and especially important which tables are included/excluded from the process. Clicking "setup" allows you to select an existing reveng.xml file or create a new one. See more details about the reveng.xml file in Chapter 5, Controlling reverse engineering.
reveng. strategy	If reveng.xml does not provide enough customization you can provide your own implementation of an ReverseEngineeringStrategy. The class need to be in the claspath of the Console Configuration, otherwise you will get class not found exceptions. See Section 5.3, “Custom strategy” for details and an example of a custom strategy.
Generate basic typed composite ids	A table that has a multi-colum primary key a <composite-id> mapping will always be created. If this option is enabled and there are matching foreign-keys each key column is still considered a 'basic' scalar (string, long, etc.) instead of a reference to an entity. If you disable this option a <key-many-to-one> instead. Note: a <many-to-one> property is still created, but is simply marked as non-updatable and non-insertable.
Detect optimistic lock columns	Automatically detect optimistic lock columns. Controllable via reveng. strategy; the current default is to use columns named VERSION or TIMESTAMP.
Detect many-to-many tables	Automatically detect many-to-many tables. Controllable via reveng. strategy.
Use custom templates	If enabled, the Template directory will be searched first when looking up the templates, allowing you to redefine how the individual templates process the hibernate mapping model.
Template directory	A path to a directory with custom templates.

3.4.2. Exporters

The Exporters tab is used to specify which type of code that should be generated. Each selection represents an Exporter that are responsible for generating the code, hence the name.

Figure 3.8. Selecting Exporters

The following table describes in short the various exporters. Remember you can add/remove any Exporters depending on your needs.

Table 3.5. Code generation "Exporter" tab fields

Field	Description
Domain code	Generates POJO's for all the persistent classes and components found in the given Hibernate configuration.
DAO code	Generates a set of DAO's for each entity found.
Hibernate XML Mappings	Generate mapping (hbm.xml) files for each entity
Hibernate XML Configuration	Generate a hibernate.cfg.xml file. Used to keep the hibernate.cfg.xml uptodate with any new found mapping files.
Schema Documentation (.html)	Generates set of html pages that documents the database schema and some of the mappings.
Generic Exporter (hbmtemplate)	Fully customizable exporter which can be used to perform custom generation.

Each Exporter listens to certain properties and these can be setup in the Properties section where you can add/remove predefined or customer properties for each of the exporters. The following table lists the time of writing pre-defined properties:

Table 3.6. Exporter Properties

Name	Description
jdk5	Generate Java 5 syntax
ejb3	Generate EJB 3 annotations
for_each	Specifies which type of model elements the exporter should create a file and run through the templates. Possible values are: entity, component, configuration
template_path	Custom template directory for this specific exporter. You can use Eclipse variables.
template_name	Name for template relative to the template path
outputdir	Custom output directory for this specific exporter. You can use Eclipse variables.
file_pattern	Pattern to use for the generated files, relatively for the output dir. Example: {package-name}/{class-name}.java
dot.executable	executable to run GraphViz (only relevant, but optional for Schema documentation)

The Hibernate Mapping file editor provides XML editing functionality for the hbm.xml and cfg.xml files. The editor is based on the Eclipse WTP tools and extend its functionallity to provide Hibernate specific code completion.

Figure 3.9. XML Editing Functionality

3.5.1. Java property/class completion

Package, class, and field completion is enabled for relevant XML attributes. The auto-completion detects its context and limits the completion for e.g. <property> and only shows the properties/fields available in the enclosing <class> , <subclass> etc. It is also possible to navigate from the hbm.xml files to the relevant class/field in java code.

Figure 3.10. Navigation Functionallity

This is done via the standard hyperlink navigation functionallity in Eclipse; per default it is done by pressing F3 while the cursor is on a class/field or by pressing Ctrl and the mouse button to perform the same navigation.

For java completion and navigation to work the file needs to reside inside an Eclipse Java project, otherwise no completion will occur.

Note

Java completion does not require a Hibernate console configuration to be used.

3.5.2. Table/Column completion

Table and column completion is also available for all table and column attributes.

Figure 3.11. Table and Column Completion

Note that it requires a proper configured hibernate console configuration and this configuration should be the default for the project where the hbm.xml resides.

You can check which console configuration is selected under the Properties of a project and look under the Hibernate Settings page. When a proper configuration is selected it will be used to fetch the table/column names in the background.

Note

Currently it is not recommended to use this feature on large databases since it does not fetch the information iteratively. It will be improved in future versions.

3.5.3. Configuration property completion

In cfg.xml code completion for the value of <property> name attributes is available.

Figure 3.12. Property Completion

A reveng.xml file is used to customize and control how reverse engineering is performed by the tools. The plugins provide and editor to ease the editing of this file and hence used to configure the reverse engineering process.

The editor is intended to allow easy definition of type mappings, table include/excludes and specific override settings for columns, e.g. define a explicit name for a column when the default naming rules is not applicable.

Note that not all the features of the .reveng.xml file is exposed or fully implemented in the editor, but the main functionallity is there. To understand the full flexibility of the reveng.xml, please see Section 5.2, “hibernate.reveng.xml file”

The editor is activated as soon as an .reveng.xml file is opened. To get an initial reveng.xml file the reveng.xml wizard can be started via Ctrl+N or via the code generation launcher.

The following screentshot shows the Overview page where the wanted console configuration is selected (auto-detected if Hibernate 3 support is enabled for the project)

Figure 3.13. Overview Page

The Table Filter page allows you to specify which tables to include and exclude. Pressing refresh shows the tables from the database that have not yet been excluded.

Figure 3.14. Table Filters Page

The Type Mappings page is used for specifying type mappings from jdbc types to any Hibernate type (including usertypes) if the default rules are not applicable.

Figure 3.15. Type Mappings Page

The Table and Columns page allow the user to explicit set e.g. which hibernatetype and propertyname that should be used in the reverse engineered model.

Figure 3.16. Table and Columns Page

The Hibernate Console perspective combines a set of views which allow you to see the structure of your mapped entities/classes, edit HQL queries, execute the queries, and see the results. To use this perspective you need to create a console configuration.

3.7.1. Viewing the entity structure

To view your new configuration and entity/class structure, expand the Hibernate Console configuration by clicking on the + icon.

Clicking on the small + symbol allows you to browse the class/entity structure and see the relationships.

Figure 3.17. Hibernate Console Perspective

Hibernate Console perspective showing entity structure, query editor and result

The console configuration does not dynamically adjust to changes done in mappings and java code; to reload the configuration select the configuration and click the Reload button in the view toolbar or in the context menu.

3.7.1.1. Mapping Diagram

A mapping diagram for entities are available by right clicking on the entity you want an mapping diagram for and then choose Open Mapping Diagram

Figure 3.18. Mapping Diagram

3.7.2. Prototyping Queries

Queries can be prototyped by entering them in the HQL or Criteria editor. The query editors are opened by right-clicking the Console configuration and selecting either HQL Editor or Criteria Editor.

If the menu item is disabled then you need to first create an SessionFactory. That is done by simply expanding the Session Factory node.

Executing the query is done by clicking the green run button in the toolbar or pressing Ctrl+Enter.

Errors during creation of the SessionFactory or running the queries (e.g. if your configuration or query is incorrect) will be shown in a message dialog or inlined in the view that detected the error, you may get more information about the error in the Error Log view on the right pane.

Results of a query will be shown in the Query result view and details of possible errors (syntax errors, database errors, etc.) can be seen in the Error Log view.

Note

HQL queries are executed by default using list() thus without any limit of the size of the output the query could return a large result set. You might run out of memory. To avoid this you can put a value in the Max results field to reduce the number of elements returned.

3.7.2.1. Dynamic Query Translator

If the Hibernate Dynamic Query Translator view is visible while writing in the HQL editor it will show the generated SQL for a HQL query.

Figure 3.19. Hibernate Dynamic Query Translator View

The translation is done each time you stop typing into the editor, if there are an error in the HQL the parse exception will be shown embedded in the view.

3.7.3. Properties view

The Properties view shows the structure of any selected persistent object in the results view. Editing is not yet supported.

Figure 3.20. Properties View

It is possible to configure the eclipse plugin to route all logging made by the plugins and hibernate code it self to the Error log view in Eclipse.

This is done by editing the hibernate-log4j.properties in org.hibernate.eclipse/ directory/jar. This file includes a default configuration that only logs WARN and above to a set of custom appenders (PluginFileAppender and PluginLogAppender). You can change these settings to be as verbose or silent as you please - see hibernate documentation for interesting categories and log4j documentation for how to configure logging via a log4j property file.

The hibernate-tools.jar contains the core for the Hibernate Tools. It is used as the basis for both the Ant tasks described in this document and the eclipse plugins both available from tools.hibernate.org The hibernate-tools.jar is located in your eclipse plugins directory at /plugins/org.hibernate.eclipse.x.x.x/lib/tools/hibernate-tools.jar.

This jar is 100% independent from the eclipse platform and can thus be used independently of eclipse.

To use the ant tasks you need to have the hibernatetool task defined. That is done in your build.xml by inserting the following xml (assuming the jars are in the lib directory):

<path id="toolslib">
 <path location="lib/hibernate-tools.jar" />
 <path location="lib/hibernate3.jar" />
 <path location="lib/freemarker.jar" />
 <path location="${jdbc.driver.jar}" />
</path>
   
<taskdef name="hibernatetool" 
         classname="org.hibernate.tool.ant.HibernateToolTask" 
         classpathref="toolslib" />

this <taskdef> defines a Ant task called <hibernatetool> which now can be used anywhere in your ant build.xml files. It is important to include all the Hibernate Tools dependencies as well as the jdbc driver.

Notice that to use the annotation based Configuration you must get a release.

When using the <hibernatetool> task you have to specify one or more of the following:

<hibernatetool
  destdir="defaultDestinationDirectory"               (1)
  templatepath="defaultTemplatePath"                  (2)
>                                                     (3)
  <classpath ...>
  <property key="propertyName" value="value"/>
  <propertyset ...>                                   (4)
  (<configuration ...>|<annotationconfiguration ...>| (5)
   <jpaconfiguration ...>|<jdbcconfiguration ...>)
  (<hbm2java>,<hbm2cfgxml>,<hbmtemplate>,...*)        (6)
</hibernatetool>

<hibernatetool destdir="${build.dir}/generated">
 <configuration configurationfile="hibernate.cfg.xml"/>
 <hbm2java/>
</hibernatetool>

<hibernatetool destdir="${build.dir}/generated">
 <classpath>
  <path location="${build.dir}/classes"/>
 </classpath>

 <configuration configurationfile="hibernate.cfg.xml"/>
 <hbm2ddl/>
 <hbm2dao/>
 <hbmtemplate
  filepattern="{package-name}/I{class-name}Constants.java"
  templatepath="${etc.dir}/customtemplates"
  template="myconstants.vm"  
 />
</hibernatetool>

hibernatetool supports four different Hibernate configurations: A standard Hibernate configuration ( <configuration> ), Annotation based configuration ( <annotationconfiguration> ), JPA persistence based configuration ( <jpaconfiguration> ) and a JDBC based configuration ( <jdbcconfiguration> ) for use when reverse engineering.

Each have in common that they are able to build up a Hibernate Configuration object from which a set of exporters can be run to generate various output. Note: output can be anything, e.g. specific files, statments execution against a database, error reporting or anything else that can be done in java code.

The following section decribes what the the various configuration can do, plus list the individual settings they have.

<configuration
  configurationfile="hibernate.cfg.xml"               (1)
  propertyfile="hibernate.properties"                 (2)
  entityresolver="EntityResolver classname"           (3)
  namingstrategy="NamingStrategy classname"           (4)
>
  <fileset...>                                        (5)
  
</configuration>

<hibernatetool destdir="${build.dir}/generated">
 <configuration propertyfile="{etc.dir}/hibernate.properties">
   <fileset dir="${src.dir}">
   <include name="**/*.hbm.xml"/>
   <exclude name="**/*Test.hbm.xml"/>
  </fileset>
 </configuration>

 <!-- list exporters here -->

</hibernatetool>

<hibernatetool destdir="${build.dir}/generated">
 <annotationconfiguration
  configurationfile="hibernate.cfg.xml"/>

 <!-- list exporters here -->

</hibernatetool>

<path id="ejb3toolslib">
 <path refid="jpatoolslib"/> <!-- ref to previously defined toolslib -->
 <path location="lib/hibernate-annotations.jar" />
 <path location="lib/ejb3-persistence.jar" />
 <path location="lib/hibernate-entitymanager.jar" />
 <path location="lib/jboss-archive-browsing.jar" />
 <path location="lib/javaassist.jar" /> 
</path>
   
<taskdef name="hibernatetool" 
         classname="org.hibernate.tool.ant.HibernateToolTask" 
         classpathref="jpatoolslib" />

<hibernatetool destdir="${build.dir}">
 <jpaconfiguration persistenceunit="caveatemptor"/>
 <classpath>
  <!-- it is in this classpath you put your classes dir,
   and/or jpa persistence compliant jar -->
  <path location="${build.dir}/jpa/classes" />
 </classpath>

 <!-- list exporters here -->

</hibernatetool>

<jdbcconfiguration
  ...
  packagename="package.name"                            (1)
  revengfile="hibernate.reveng.xml"                     (2)
  reversestrategy="ReverseEngineeringStrategy classname"(3)
  detectmanytomany="true|false"                         (4)
  detectoptmisticlock="true|false"                      (5)
>
  ...
</jdbcconfiguration>

<hibernatetool>
 <jdbcconfiguration propertyfile="etc/hibernate.properties" />
 <hbm2hbmxml destdir="${build.dir}/src" /> 
</hibernatetool>

Exporters is the parts that does the actual job of converting the hibernate metamodel into various artifacts, mainly code. The following section describes the current supported set of exporters in the Hibernate Tool distribution. It is also possible for userdefined exporters, that is done through the <hbmtemplate> exporter.

<hbm2ddl
 export="true|false"                                  (1)
 update="true|false"                                  (2)
 drop="true|false"                                    (3)
 create="true|false"                                  (4)
 outputfilename="filename.ddl"                        (5)
 delimiter=";"                                        (6)
 format="true|false"                                  (7)(8)
 haltonerror="true|false"
>

<hibernatetool destdir="${build.dir}/generated">
 <configuration configurationfile="hibernate.cfg.xml"/>
 <hbm2ddl export="false" outputfilename="sql.ddl"/>
</hibernatetool>

<hbm2java
 jdk5="true|false"                                    (1)
 ejb3="true|false"                                    (2)
>

<hibernatetool destdir="${build.dir}/generated">
 <configuration configurationfile="hibernate.cfg.xml"/>
 <hbm2java jdk5="true"/>
</hibernatetool>

<hbm2hbmxml/>

<hibernatetool destdir="${build.dir}/generated">
 <configuration configurationfile="hibernate.cfg.xml"/>
 <hbm2hbmxml/>
</hibernatetool>

<hibernatetool destdir="${build.dir}/generated">
 <annotationconfiguration configurationfile="hibernate.cfg.xml"/>
 <hbm2hbmxml/>
</hibernatetool>

<hbm2cfgxml
  ejb3="true|false"                                   (1)
/>

<hbm2doc/>

<query
 destfile="filename">
 <hql>[a HQL query string]</hql>
</query>

<hibernatetool>
 <configuration configurationfile="hibernate.cfg.xml"/>
 <query>from java.lang.Object</query>
</hibernatetool>

<hibernatetool>
 <configuration configurationfile="hibernate.cfg.xml"/>
 <query destfile="queryresult.txt">
   <hql>select c.name from Customer c where c.age > 42</hql>
   <hql>from Cat</hql>
</hibernatetool>

<hbmtemplate
 filepattern="{package-name}/{class-name}.ftl"
 template="somename.ftl"
 exporterclass="Exporter classname"
/>

 <hibernatetool destdir="${destdir}">
  <jdbcconfiguration 
     configurationfile="hibernate.cfg.xml" 
     packagename="my.model"/>   
  
  <!-- setup properties -->  
  <property key="appname" value="Registration"/>
  <property key="shortname" value="crud"/>
    
  <hbmtemplate 
     exporterclass="my.own.Exporter" 
     filepattern="."/>
        
</hibernatetool>

Exporters can be controlled by user properties. The user properties is specificed via <property> or <propertyset> and each exporter will have access to them directly in the templates and via Exporter.setProperties().

<property key="descriptors" value="true"/>

<property key="hibernatetool.sometool.toolclass" value="x.y.z.NameOfToolClass"/>

<hibernatetool destdir="${build.dir}/generated">
<configuration 
   configurationfile="etc/hibernate.cfg.xml"/>
 <hbmtemplate 
   templateprefix="pojo/" 
   template="pojo/Pojo.ftl" 
   filepattern="{package-name}/{class-name}.java">
  <property key="jdk5" value="true" />
  <property key="ejb3" value="true" />
 </hbmtemplate>
</hibernatetool>

The default strategy uses some rules for mapping JDBC artifact names to java artifact names. It also provide basic typemappings from JDBC types to Hibernate types. It is the default strategy that uses the packagename attribute to convert a table name to a fully qualified classname.

To have fine control over the process a hibernate.reveng.xml file can be provided. In this file you can specify type mappings and table filtering. This file can be created by hand (its just basic XML) or you can use the Hibernate plugins which have a specialized editor.

The following is an example of a reveng.xml. Following the example is more details about the format.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering 
  SYSTEM "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" >

<hibernate-reverse-engineering>

<type-mapping>
 <!-- jdbc-type is name fom java.sql.Types -->
 <sql-type jdbc-type="VARCHAR" length='20' hibernate-type="SomeUserType" /> 
 <sql-type jdbc-type="VARCHAR" length='1' hibernate-type="yes_no" />
 <!-- length, scale and precision can be used to specify the mapping precisly -->
 <sql-type jdbc-type="NUMERIC"  precision='1' hibernate-type="boolean" /> 
 <!-- the type-mappings are ordered. This mapping will be consulted last, 
  thus overriden by the previous one if precision=1 for the column -->
 <sql-type jdbc-type="NUMERIC"  hibernate-type="long" /> 
</type-mapping>

<!-- BIN$ is recycle bin tables in Oracle -->
<table-filter match-name="BIN$.*" exclude="true" /> 

<!-- Exclude DoNotWantIt from all catalogs/schemas -->
<table-filter match-name="DoNotWantIt" exclude="true" /> 

<!-- exclude all tables from the schema SCHEMA in catalog BAD. -->
<table-filter match-catalog="BAD" match-schema="SCHEMA" match-name=".*" exclude="true" /> 

<!-- table allows you to override/define how reverse engineering 
     are done for a specific table -->
<table name="ORDERS"> 
 <primary-key>
   <!-- setting up a specific id generator for a table -->
  <generator class="sequence">
    <param name="table">seq_table</param>
  </generator>
   <key-column name="CUSTID"/>
 </primary-key>
 <column name="NAME" property="orderName" type="string" />
 <!-- control many-to-one and set names for a specific named foreign key constraint -->
 <foreign-key constraint-name="ORDER_CUST">
   <many-to-one property="customer"/>
   <set property="orders"/>
 </foreign-key>
</table>

</hibernate-reverse-engineering>

<schema-selection/>

<schema-selection match-catalog=".*" match-schema=".*" match-table=".*"/>

<schema-selection match-schema="MY_SCHEMA"/>

<schema-selection match-schema="MY_SCHEMA"/>
<schema-selection match-schema="COMMON_SCHEMA" match-table="CITY"/>
<schema-selection match-schema="COMMON_SCHEMA" match-table="CODES_.*"/>

<type-mapping>
 <sql-type
  jdbc-type="integer value or name from java.sql.Types"
  length="a numeric value"
  precision="a numeric value"
  scale="a numeric value"
  not-null="true|false"  
  hibernate-type="hibernate type name"  
 />
</type-mapping>

<type-mapping>
 <sql-type jdbc-type="NUMERIC" precision="15" hibernate-type="big_decimal"/>
 <sql-type jdbc-type="NUMERIC" not-null="true" hibernate-type="long" />
 <sql-type jdbc-type="NUMERIC" not-null="false" hibernate-type="java.lang.Long" />
 <sql-type jdbc-type="VARCHAR" length="1" not-null="true" hibernate-type="java.lang.Character"/>
 <sql-type jdbc-type="VARCHAR" hibernate-type="your.package.TrimStringUserType"/>
 <sql-type jdbc-type="VARCHAR" length="1" hibernate-type="char"/>
 <sql-type jdbc-type="VARCHAR" hibernate-type="string"/>
</type-mapping>

<table-filter
 match-catalog="catalog_matching_rule"                (1)
 match-schema="schema_matching_rule"                  (2)
 match-name="table_matching_rule"                     (3)
 exclude="true|false"                                 (4)
 package="package.name"                               (5)
/>

<table 
 catalog="catalog_name"                               (1)
 schema="schema_name"                                 (2)
 name="table_name"                                    (3)
 class="ClassName"                                    (4)
>
 <primary-key.../>
 <column.../>
 <foreign-key.../>
</table>

<primary-key
 <generator class="generatorname">                    (1)
   <param name="param_name">parameter value</param>   (2)
 </generator>
 <key-column...>                                      (3)
</primary-key>

<column
 name="column_name"                                   (1)
 jdbc-type="java.sql.Types type"                      (2)
 type="hibernate_type"                                (3)
 property="propertyName"                              (4)
 exclude="true|false"                                 (5)
/>

<foreign-key
  constraint-name="foreignKeyName"                    (1)
  foreign-catalog="catalogName"                       (2)
  foreign-schema="schemaName"                         (3)
  foreign-table="tableName"                           (4)
 >
 <column-ref local-column="columnName" foreign-column=(5)"foreignColumnName"/>
 <many-to-one                                         (6)
   property="aPropertyName"
   exclude="true|false"/>                             (7)
 <set 
   property="aCollectionName"
   exclude="true|false"/>
</foreign-key>

It is possible to implement a user strategy. Such strategy must implement org.hibernate.cfg.reveng.ReverseEngineeringStrategy. It is recommended that one uses the DelegatingReverseEngineeringStrategy and provide a public constructor which takes another ReverseEngineeringStrategy as argument. This will allow you to only implement the relevant methods and provide a fallback strategy. Example of custom delegating strategy which converts all column names that ends with "PK" into a property named "id".

public class ExampleStrategy extends DelegatingReverseEngineeringStrategy {

 public ExampleStrategy(ReverseEngineeringStrategy delegate) {
  super(delegate);
 }

 public String columnToPropertyName(TableIdentifier table, String column) {
  if(column.endsWith("PK")) {
   return "id";
  } else {
   return super.columnToPropertyName(table, column);
  }
 }
}

By default the reverse engineering is performed by reading using the JDBC database metadata API. This is done via the class org.hibernate.cfg.reveng.dialect.JDBCMetaDataDialect which is an implementation of org.hibernate.cfg.reveng.dialect.MetaDataDialect.

The default implementation can be replaced with an alternative implementation by setting the property hibernatetool.metadatadialect to a fully qualified classname for a class that implements JDBCMetaDataDialect.

This can be used to provide database specific optimized metadata reading. If you create an optimized/better metadata reading for your database it will be a very welcome contribution.

The <meta> tag is a simple way of annotating the hbm.xml with information, so tools have a natural place to store/read information that is not directly related to the Hibernate core.

You can use the <meta> tag to e.g. tell hbm2java to only generate "protected" setters, have classes always implement a certain set of interfaces or even have them extend a certain base class and even more.

The following example shows how to use various <meta> attributes and the resulting java code.

<class name="Person">
    <meta attribute="class-description">
        Javadoc for the Person class
        @author Frodo
    </meta>
    <meta attribute="implements">IAuditable</meta>
    <id name="id" type="long">
        <meta attribute="scope-set">protected</meta>
        <generator class="increment"/>
    </id>
    <property name="name" type="string">
        <meta attribute="field-description">The name of the person</meta>
    </property>
</class>

The above hbm.xml will produce something like the following (code shortened for better understanding). Notice the Javadoc comment and the protected set methods:

// default package

import java.io.Serializable;
import org.apache.commons.lang.builder.EqualsBuilder;
import org.apache.commons.lang.builder.HashCodeBuilder;
import org.apache.commons.lang.builder.ToStringBuilder;

/** 
 *         Javadoc for the Person class
 *         @author Frodo
 */
public class Person implements Serializable, IAuditable {

    public Long id;

    public String name;

    public Person(java.lang.String name) {
        this.name = name;
    }

    public Person() {
    }

    public java.lang.Long getId() {
        return this.id;
    }

    protected void setId(java.lang.Long id) {
        this.id = id;
    }

    /** 
     * The name of the person
     */
    public java.lang.String getName() {
        return this.name;
    }

    public void setName(java.lang.String name) {
        this.name = name;
    }

}

Attributes declared via the <meta> tag are per default "inherited" inside an hbm.xml file.

What does that mean? It means that if you e.g want to have all your classes implement IAuditable then you just add an <meta attribute="implements">IAuditable</meta> in the top of the hbm.xml file, just after <hibernate-mapping>. Now all classes defined in that hbm.xml file will implement IAuditable!

To avoid having a <meta> tag inherited then you can simply specify inherit = "false" for the attribute, e.g. <meta attribute = "scope-class" inherit = "false">public abstract</meta> will restrict the "class-scope" to the current class, not the subclasses.

<hibernate-mapping>
  <class name="Person">
    <meta attribute="use-in-tostring">true</meta>
    <meta attribute="use-in-equals">true</meta>
    ...
  </class>
</hibernate-mapping>

<hibernate-mapping>              
  <class name="events.Event" table="EVENTS">
    <meta attribute="use-in-tostring">true</meta>
    <meta attribute="use-in-equals">true</meta>                  
    <id name="id" column="EVENT_ID">
        <generator class="native"/>
    </id>
    <property name="date" type="timestamp" column="EVENT_DATE"/>
    <property name="title"/>
    <set name="participants" table="PERSON_EVENT" inverse="true">
        <key column="EVENT_ID"/>
        <many-to-many column="PERSON_ID" class="events.Person"/>
    </set>                    
  </class>
</hibernate-mapping>

<hibernate-mapping>              
  <class name="events.Event" table="EVENTS">                  
    <id name="id" column="EVENT_ID">
        <meta attribute="use-in-tostring">true</meta>
        <generator class="native"/>
    </id>
    <property name="date" type="timestamp" column="EVENT_DATE"/>
    <property name="title">
      <meta attribute="use-in-tostring">true</meta>
      <meta attribute="use-in-equals">true</meta>      
    </property>
    <set name="participants" table="PERSON_EVENT" inverse="true">
        <key column="EVENT_ID"/>
        <many-to-many column="PERSON_ID" class="events.Person"/>
    </set>                    
  </class>
</hibernate-mapping>

<hibernate-mapping>
    <class name="Person">
    <meta attribute="class-description">
        Javadoc for the Person class
        @author Frodo
    </meta>
    <meta attribute="implements">IAuditable</meta>
    <id name="id" type="long">
        <meta attribute="scope-set">protected</meta>
        <meta attribute="use-in-tostring">true</meta>        
        <generator class="increment"/>
    </id>
    <property name="name" type="string">
        <meta attribute="field-description">The name of the person</meta>
        <meta attribute="use-in-tostring">true</meta>
    </property>
  </class>
</hibernate-mapping>

<#foreach property in pojo.getAllPropertiesIterator()>
    ${pojo.getPropertyGetModifiers(property)} ${pojo.getJavaTypeName(property, jdk5)} ${pojo.getGetterSignature(property)}() {
        return this.${property.name};
    }
    
    ${pojo.getPropertySetModifiers(property)} void set${pojo.getPropertyName(property)}(${pojo.getJavaTypeName(property, jdk5)} ${property.name}) {
        this.${property.name} = ${property.name};
    }
</#foreach>

<#foreach property in pojo.getAllPropertiesIterator()>
    ${pojo.getPropertyGetModifiers(property)} ${pojo.getJavaTypeName(property, jdk5)} ${pojo.getGetterSignature(property)}() {
        return this.${property.name};
    }
    
    ${pojo.getPropertySetModifiers(property)} void set${pojo.getPropertyName(property)}(${pojo.getJavaTypeName(property, jdk5)} ${property.name}) {
      <#if pojo.hasMetaAttribute(property, "pre-cond")> 
       ${c2j.getMetaAsString(property, "pre-cond","\n")} 
      </#if>      
      this.${property.name} = ${property.name};
      <#if pojo.hasMetaAttribute(property, "post-cond")> 
       ${c2j.getMetaAsString(property, "post-cond","\n")} 
      </#if>        
}
</#foreach>

<hibernate-mapping>
  <class name="Person">
  <id name="id" type="long">        
      <generator class="increment"/>
  </id>
  <property name="firstName" type="string">
      <meta attribute="pre-cond"><![CDATA[
      if ((firstName != null) && (firstName.length() == 0) ) {
        throw new IllegalArgumentException("firstName can not be an empty String");
      }]]>
      </meta>
  </property>
</class>
</hibernate-mapping>

    <target name="hbm2java">
        <taskdef name="hibernatetool"
          classname="org.hibernate.tool.ant.HibernateToolTask"
          classpathref="lib.classpath"/>
        <hibernatetool destdir="${hbm2java.dest.dir}"
          templatepath="${hbm.template.path}">
          <classpath>
            <path refid="pojo.classpath"/>
          </classpath>        
          <configuration>
            <fileset dir="${hbm2java.src.dir}">
              <include name="**/*.hbm.xml"/>
            </fileset>
          </configuration>
          <hbm2java/>
        </hibernatetool>
    </target>

// default package
import java.io.Serializable;
public class Person implements Serializable {

    public Long id;

    public String name;

    public Person(java.lang.String name) {
        this.name = name;
    }

    public Person() {
    }

    public java.lang.Long getId() {
        return this.id;
    }

    public void setId(java.lang.Long id) {
        this.id = id;
    }
    
    public java.lang.String getName() {
        return this.name;
    }

    public void setName(java.lang.String name) {
        if ((name != null) && (name.length() == 0)) {
            throw new IllegalArgumentException("name can not be an empty String");
        }
        this.name = name;
    }
}