The most simple way to configure the plugin is, to put all the hibernate-configuration in a hibernate.properties-file on your classpath. Put the file in the resources-folder. Maven will put it in the class-folder of your webapp, where it will be picked up by this plugin as well as by Hibernate 4.
-
Doing so, the only additionally configuration needed, to activat the plugin is the following entry in the plugins-section of your pom.xml:
The most simple way to configure the plugin is, to put all the hibernate-configuration in a hibernate.properties-file on your classpath. Put the file in the resources-folder. Maven will put it in the class-folder of your webapp, where it will be picked up by this plugin as well as by Hibernate 4.
+
Doing so, the only additionally configuration needed, to activat the plugin is the following entry in the plugins-section of your pom.xml:
But be aware, that in this case the database-url, that is build in the application is the same that is used while testing, where the database is droped and recreated by the plugin. So, you should never fire up this configuration on your production system, or your database might be erased!
+</plugin>
+
But be aware, that in this case the database-url, that is build in the application is the same that is used while testing, where the database is droped and recreated by the plugin. So, you should never fire up this configuration on your production system, or your database might be erased!
Hence, you should specify a different url for testing like in the following snippet:
Configuration properties, that are set in the configuration-section of the plugin-configuration cannnot be overwritten elsewere (for details see Configuration-Method-Precedence). You never can overwrite them by accident when specifying a property on the commandline or in your settings.xml.
-
-
Configuration through maven-properties
+</plugin>
+
Configuration properties, that are set in the configuration-section of the plugin-configuration cannnot be overwritten elsewere (for details see Configuration-Method-Precedence). You never can overwrite them by accident when specifying a property on the commandline or in your settings.xml.
+
Configuration through maven-properties
Alternatively, it is possible, to configure the plugin via maven-properties. Each relevant configuration-option has a corresponding maven-property (for a full list see the Documentation of the export-Mojo). These are named after the Hibernate JDBC Properties:
-
hibernate.connection.driver_class
-
hibernate.dialect
-
hibernate.connection.url
-
hibernate.connection.username
-
hibernate.connection.password
-
So, instead of writing the hibernate-configuration in the properties-file, like above, you could put it in the properties-section of your pom.xml.
+
hibernate.connection.driver_class
+
hibernate.dialect
+
hibernate.connection.url
+
hibernate.connection.username
+
hibernate.connection.password
+
So, instead of writing the hibernate-configuration in the properties-file, like above, you could put it in the properties-section of your pom.xml.
Thogether with the plugin-definition from above, the following would be a complete configuration (again, the database-url was overwritten in the plugin-configuration, to be sure to have a separate database for testing):
The parameter hibernateProperties (name of the hibernate-properties-file to use, defaults to hibernate.properties) can only be configured through this approach.
If you are in doubt about where a configuration-value comes from, run maven with the debug-output enabled: mvn -X hibernate4:export and be aware, that maven-properties can be overwitten on the command-line, in your ~/.m2/settings.xml and in a profile.
+
If you are in doubt about where a configuration-value comes from, run maven with the debug-output enabled: mvn -X hibernate4:export and be aware, that maven-properties can be overwitten on the command-line, in your ~/.m2/settings.xml and in a profile.
The plugin-configuration comes last and overwrites everything else. That way, you can be sure, that a configuration-value, that is specified in the plugin-configuration will never be overwritten by any other configuration-method.
If you realy need to overwrite plugin-configuration-values with maven-properties, you can use maven-properties in the plugin-configuration:
If you are new to hibernate4-maven-plugin, in many cases, the Configuration-Method-Precedence may be the source of configuration errors. To solve this problem, you should run maven with the debugging output enabled. For example, by executing:
-
-
mvn -X compile hibernate4:export
-
(The compile might be necessary, because hibernate4-maven-plugin has to scan the compiled classes for annotations!)
-
Unlike the majority of the maven-plugins, hibernate4-maven-plugin was designed to give a good many hints, when debugging is enabled. Because, if you do not know, what went wrong, you can't fix it!
-
But be warned:hibernate4-maven-plugin tends to be very chatty ;)
Description: This module provides extensions to Aether for utilizing the Maven POM and Maven repository metadata for artifacts resolution
and download.
Description: Plexus Component "Java 5" Annotations, to describe plexus components properties in java sources with
standard annotations instead of javadoc annotations.
The hibernate4-maven-plugin computes MD5-sums for all found annotated classes and stores them together with the generated schema. If no classes were changed or added and the dialect wasn't changed too, it automatically skips the configured schema-export, to speed up the development cycle.
-
The plugin signals, that the execution was skipped by setting the maven property $hibernate.export.skipped to true. This may be helpful, because other plugins like dbunit-pluginmay fail, when the execution is skipped.
-
If you need the hibernate4-maven-plugin to never skip execution automatically, you can force it to do so, if you set the parameter force to true:
The hibernate4-maven-plugin computes MD5-sums for all found annotated classes and stores them together with the generated schema. If no classes were changed or added and the dialect wasn't changed too, it automatically skips the configured schema-export, to speed up the development cycle.
+
The plugin signals, that the execution was skipped by setting the maven property $hibernate.export.skipped to true. This may be helpful, because other plugins like dbunit-pluginmay fail, when the execution is skipped.
+
If you need the hibernate4-maven-plugin to never skip execution automatically, you can force it to do so, if you set the parameter force to true:
Hibernate 4 Maven Plugin - A simple Plugin for generating a Database-Schema from Hibernate 4 Mapping-Annotations.
-
hibernate4-maven-plugin is a plugin for generating a database-schema from your Hibernate-4-Mappings and create or update your database accordingly. Its main usage is to automatically create and populate a test-database for unit-tests in cooperation with the dbunit-maven-plugin.
+
+
A simple Plugin for generating a Database-Schema from Hibernate 4 Mapping-Annotations.
hibernate4-maven-plugin is a plugin for generating a database-schema from your Hibernate-4-Mappings and create or update your database accordingly. Its main usage is to automatically create and populate a test-database for unit-tests in cooperation with the dbunit-maven-plugin.
The plugin was designed with three main goals in mind:
It should be easy to use.
It should be maximal unlikely, to erase a producation-database by accident.
It should not slow down the development cycle.
-
To achieve the first goal, the convention-over-configuration paradigma was applied and the plugin was stuffed with usefull logging-messages. So, if in doubt, just turn on the debugging output with the mvn -X ....
+
To achieve the first goal, the convention-over-configuration paradigma was applied and the plugin was stuffed with usefull logging-messages. So, if in doubt, just turn on the debugging output with the mvn -X ....
To achieve the second goal, the precedence in which the configuration locations are consulted was layouted in a way that makes it possible, to prevent overwrites of the wrong database by accident.
Last but not least, in order to not slow down the development cycle, the hibernate4-maven-plugin only executes the schema-export, if the mapping or the dialect changes (or if you force it to do so).
See Configuration Examples for Usage-Explanations and simple examples of how to use this plugin.
-
See hibernate4:export and Plugin Documentation for the full autogenerated documentation. These are mostly configuration-options of the Hibernate-Tools SchemaExport and SchemaUpdate, that do the work in the background.
-
-
Releases
+
See hibernate4:export and Plugin Documentation for the full autogenerated documentation. These are mostly configuration-options of the Hibernate-Tools SchemaExport and SchemaUpdate, that do the work in the background.
hibernate4-maven-plugin does not scan transitive dependencies for annotated classes. If some of your annotated classes are hidden in a transitive dependency, you can simply add that dependency explicitly.
-
-
hibernate4-maven-plugin always needs a database-connection
-
The default-configuration uses the EXPORT-target of the SchemaExport-Tool. If you do not need to create a database with the evaluated schema, you can use the NONE- or the SCRIPT-target. This can be achieved with the command-line parameter -Dhibernate.export.target=SCRIPT or with the following configuration:
hibernate4-maven-plugin does not scan transitive dependencies for annotated classes. If some of your annotated classes are hidden in a transitive dependency, you can simply add that dependency explicitly.
+
hibernate4-maven-plugin always needs a database-connection
+
The default-configuration uses the EXPORT-target of the SchemaExport-Tool. If you do not need to create a database with the evaluated schema, you can use the NONE- or the SCRIPT-target. This can be achieved with the command-line parameter -Dhibernate.export.target=SCRIPT or with the following configuration:
But even when no database is to be created, hibernate always needs to know the dialect. Hence, the plugin will fail if this parameter is missing!
-
-
Dependency for driver-class XYZ is missing
-
One regular problem is the scope of the jdbc-driver-dependency. It is very unlikely, that this dependency is needed at compile-time. So a tidy maven-developer would usually scope it for runtime.
-
But this will break the execution of the hibernate4-maven-plugin. Since it will not be able to see the needed dependency, it will fail with an error-message like:
-
+</configuration>
+
But even when no database is to be created, hibernate always needs to know the dialect. Hence, the plugin will fail if this parameter is missing!
+
Dependency for driver-class XYZ is missing
+
One regular problem is the scope of the jdbc-driver-dependency. It is very unlikely, that this dependency is needed at compile-time. So a tidy maven-developer would usually scope it for runtime.
+
But this will break the execution of the hibernate4-maven-plugin. Since it will not be able to see the needed dependency, it will fail with an error-message like:
[INFO] Gathered hibernate-configuration (turn on debugging for details):
[INFO] hibernate.connection.username = sa
[INFO] hibernate.connection.password =
@@ -85,14 +419,13 @@
[INFO] Total time: 2 seconds
[INFO] Finished at: Thu Nov 29 11:31:14 CET 2012
[INFO] Final Memory: 32M/342M
-[INFO] ------------------------------------------------------------------------
This is also the best way, if you use a different jdbc-driver for testing, than in production. Because otherwise, this dependency will unnecessarily bloat the runtime-dependencies of your project.
-
-
DBUnit fails after execution of hibernate4 was skipped because nothing has changed
-
If hibernate4-maven-plugin skips its excecution, this may lead to errors in other plugins. For example, when importing sample-data in the automatically created database with the help of the dbunit-plugin, the CLEAN_INSERT-operation may fail because of foreign-key-constraints, if the database was not recreated, because the hibernate4-maven-plugin has skipped its excecution.
+</plugin>
+
This is also the best way, if you use a different jdbc-driver for testing, than in production. Because otherwise, this dependency will unnecessarily bloat the runtime-dependencies of your project.
+
DBUnit fails after execution of hibernate4 was skipped because nothing has changed
+
If hibernate4-maven-plugin skips its excecution, this may lead to errors in other plugins. For example, when importing sample-data in the automatically created database with the help of the dbunit-plugin, the CLEAN_INSERT-operation may fail because of foreign-key-constraints, if the database was not recreated, because the hibernate4-maven-plugin has skipped its excecution.
A quick fix to this problem is, to force hibernate4-maven-plugin to export the schema every time it is running. But to recreate the database on every testrun may noticeable slow down your development cycle, if you have to wait for slow IO.
-
To circumvent this problem, hibernate4-maven-plugin signals a skipped excecution by setting the maven property $hibernate.export.skipped to true. You can configure other plugins to react on this signal. For example, the dbunit-plugin can be configured to skip its excecution, if hibernate4-maven-plugin was skipped like this:
-
+
To circumvent this problem, hibernate4-maven-plugin signals a skipped excecution by setting the maven property $hibernate.export.skipped to true. You can configure other plugins to react on this signal. For example, the dbunit-plugin can be configured to skip its excecution, if hibernate4-maven-plugin was skipped like this:
The database will not be recreated after a manual drop/clean
+</plugin>
+
The database will not be recreated after a manual drop/clean
If one manually drops the database or removes the hsqldb-files, it will not be recreated by the hibernate4-maven-plugin, because it cannot detect, that the database needs to be recreated. This happens, because the plugin will not recreate the database if neither the configuration nor the annotated classes have changed, because an unnecessary drop-create-cycle might take a long time. The plugin will report that like this:
-
[INFO] No modified annotated classes found and dialect unchanged.
-[INFO] Skipping schema generation!
-
If one always uses mvn clean for cleanup, this will not happen. Otherwise the recreation must be forced:
The hibernate4:export goal is not executed, when tests are skipped
-
The hibernate4-maven-plugin automatically skips its execution, when maven.test.skip is set to true. If you need it to be always executed, you can configure that explicitly like this:
-
+[INFO] Skipping schema generation!
+
If one always uses mvn clean for cleanup, this will not happen. Otherwise the recreation must be forced:
The hibernate4:export goal is not executed, when tests are skipped
+
The hibernate4-maven-plugin automatically skips its execution, when maven.test.skip is set to true. If you need it to be always executed, you can configure that explicitly like this:
This document provides an overview of the various documents and links that are part of this project's general information. All of this content is automatically generated by Maven on behalf of the project.
This document provides an overview of the various documents and links that are part of this project's general information. All of this content is automatically generated by Maven on behalf of the project.
This document provides information on the members of this project. These are the individuals who have contributed to the project in one form or another.
In most use-cases, the hibernate4-maven-plugin is used to create a test-database automatically. In this use-cases, it is very likely, that it will result in mistakes/errors, if the goal is executed, when the tests are skipped. For example, one might manually overwrite the database-url with the url of the production-database, in order to run other tests, like starting a local webserver with the jetty-maven-plugin. If the export-goal would be executed in such a scenario, it might erase the hole production-database, which is not very desireable.
-
Because of this, the configuration-parameter skip defaults to the value of the proptery maven.test.skip. This way, the execution of the hibernate4-maven-plugin is skipped automatically, when the tests are skipped. Think of it as a build-in security-belt.
-
If you do not like that, because you need the plugin to always execute the export-goal, even if the tests are skipped you can configure that explicitly, by setting the configuration-parameter skip to false:
In most use-cases, the hibernate4-maven-plugin is used to create a test-database automatically. In this use-cases, it is very likely, that it will result in mistakes/errors, if the goal is executed, when the tests are skipped. For example, one might manually overwrite the database-url with the url of the production-database, in order to run other tests, like starting a local webserver with the jetty-maven-plugin. If the export-goal would be executed in such a scenario, it might erase the hole production-database, which is not very desireable.
+
Because of this, the configuration-parameter skip defaults to the value of the proptery maven.test.skip. This way, the execution of the hibernate4-maven-plugin is skipped automatically, when the tests are skipped. Think of it as a build-in security-belt.
+
If you do not like that, because you need the plugin to always execute the export-goal, even if the tests are skipped you can configure that explicitly, by setting the configuration-parameter skip to false:
Or, if you want the export-goal to be executed by default and to be skipped if you say so, you can bind the value of the configuration-parameter skip to a custom property. For example:
-
+</plugin>
+
Or, if you want the export-goal to be executed by default and to be skipped if you say so, you can bind the value of the configuration-parameter skip to a custom property. For example: