Spend hours this weekend to understand and get Annotation driven schema and tests generation going.
*See notes*
What it is about, is that provided one language and syntax you can configure your Objects from source directly from one place, that is what and how it should persist (save).
This all without having to regard and worry about the database implementation or background configuration. Thus builds and tests can be run automatically on the code and objects that are being compiled and then immediately run; without having to model or prepare neither configure a database for this purpose. So beside automated builds and plain internal environment based tests, externally interfaced dependant test can be fully run and checked against a real database as well without deployment.
Currently, the technology behind it requires a lot of inside knowledge of how hibernate and databases work. The number of APIs used and in what way and how is difficult to grasp and pick-up, but all is available and free over the net.
Here are some of the advantages:
1. You can construct and configure you object and its desired database record (mapping) in one place.
2. Your object is mapped and persisted automatically by hibernate to several different database flavours or dialects.
3. You can run test on builds directly in memory or to a real database of choice via standard properties.
4. Via DBUnit sample data can also be packed and executed by the tests directly against the database.
5. Maven can be fully used to deploy and run the build of the whole application container in real time and against externally different servers, depending on personal setup, configuration and choice in most suitable technologies without any manual intervention, or having to venture outside the projects maven POM script file.
Will

http://www.martinfowler.com/articles/injection.html
http://excalibur.apache.org/
In the Java community there's been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of "Inversion of Control". In this article I dig into how this pattern works, under the more specific name of "Dependency Injection", and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.