I am a core developer on the Hibernate products Annotations, EntityManager, Search and Validator. Currently I am focusing on the implementation JSR 303 - Bean Validation.
| Recent Entries |
|
25. Jan 2012
|
|
|
16. Nov 2011
|
|
|
03. Nov 2011
|
|
|
15. Sep 2011
|
|
|
03. Aug 2011
|
|
|
20. Jun 2011
|
|
|
09. Jun 2011
|
|
|
21. Mar 2011
|
|
|
07. Mar 2011
|
|
|
13. Jan 2011
|
|
|
06. Dec 2010
|
|
|
04. Nov 2010
|
|
|
01. Nov 2010
|
|
|
15. Oct 2010
|
|
|
24. Sep 2010
|
It has gone some time since I announced the last release of the Hibernate JPA Metamodel Generator. It is time to announce the release of version 1.2.0.CR1. Just as a reminder, JPA Metamodel Generator is an annotation processor which generates the canonical metamodel classes needed for using the strongly typed JPA 2 Criteria queries.
This new release is a maintenance release with a total of 20 enhancements and bug fixes. Most of these issues have been reported by users and many came even with a patch. Thanks!
METAGEN-53, METAGEN-73 and METAGEN-79 are worth mentioning explicitly. METAGEN-53 removes the dependencies to the JPA API. This means that the annotation processor is now a standalone jar without any further dependencies which makes integration of the processor into the build process and into the IDE even easier. METAGEN-73 and METAGEN-79 are about the @Generated annotation. In earlier version you had to explicitly specify the addGeneratedAnnotation option to add the annotation. Now @Generated is added by default and you have to explicitly disable it in case you want Java 5 compliant source files. Also the parameter values of the annotation have changed:
@Generated(value = "org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor", date = "2012-01-25T22:22:54.850+0100")The value is now the fully qualified classname of the annotation processor as suggested by the documentation of @Generated and you can also add the generation date by providing the processor option addGenerationDate (per default the date is not added).
As usual, you can download the release from the JBoss Maven repo or from SourceForge.
To report any issues use the Hibernate Jira project METAGEN.
Enjoy!
Moving to steadily towards a Hibernate Search 4 we just released Hibernate Search 4.0.0.CR2. In total we managedto address 32 issues. If you are interested in the details have a look at the Jira release notes.
On top of internal API polishing and the obligatory bug fixes we focused on bringing the documentation up to date. Have a look at the latest version. In particular we tried to highlight the role of the new IndexManager interface. Each Lucene index is now managed by an IndexManager instance and, except of the use cases of index sharding or sharing, there is a one to one relation between an indexed entity and an index manager. Luckily these architectural changes have no effect the basic configuration and use of Hibernate Search :-)
Make sure to also read the Hibernate Search Migration Guide when trying to upgrade to Hibernate Search 4.
The release is available via the JBoss Maven Repository under the GAV org.hibernate:hibernate-search:4.0.0.CR2 or via SourceForge.
--Hardy
Fresh back from JUDCon 2011:London, I quickly want to blog about my Hibernate OGM presentation. For the impatient, all the code and the presentation itself is available on GitHub - ogm-kitchensink. The README.md gets you started with building, testing and deploying the code. Deployment is possible into a local JBoss AS 7 instance as well as into OpenShift Express.
The demo is based on the AS 7 quickstart application kitchensink and shows a registration screen with name, email and phone number. Even though this is a very simple application there are several interesting things going on under the hood, most importantly the use of OGM :-)
AS 7 modules
The demo uses OGM in the version 3.0.0.Alpha2 which requires Hibernate Core 3.6. However, AS 7 ships with Hibernate 4. The solution to this problem is to define a Hibernate 3 module as described by Scott in Using a different persistence provider with AS 7.0.1
. The demo does exactly that. In fact it actually bundles all the steps described in the blog and let you create the required modules via a single maven command. Just check out ogm-kitchensink, make sure your JBOSS_HOME variable is set properly and run:
mvn groovy:executeThis will copy all required module jars and configuration files into the appropriate location of your local AS 7 instance.
Running the demo locally
Provided you have installed the modules and started JBoss AS, you can run the demo locally as simple as:
mvn clean package jboss-as:deploy
Arquillian
Of course the demo comes with a test. Check out MemberRegistrationTest to see how to put together a Arquillian test and then run the test either via:
$ mvn testor
$ mvn test -DremoteTests=trueCheck the profile setup in pom.xml to see the difference in the configuration.
OpenShift Express
Last but not least, let's push the demo into OpenShift Express. This is as simple as signing up for OpenShift, installing the rhc command line tools and then running:
$ rhc-create-domain -n <domain>
$ rhc-create-app -a <app> -t jbossas-7.0 --nogit
...
Success! Your application is now published here:
http://<name>-<domain>.rhcloud.com/
The remote repository is located here:
<repo-url>
...
$ git remote add openshift <repo-url>
$ git push -f openshift master
The interesting bit here is to get the required modules installed on the server side. It turns out, all you have to do is to check add them to the git repository under .openshift/modules.
Again, check out README.md, script.md and the presentation slides for more information.
Looking forward to some feedback,
Hardy
Moving from Alpha2 to Beta1, I am happy to announce the release of Hibernate Search 4.0.0.Beta1. For a full list of changes refer to the Jira release notes. Let's look at some of the changes in detail though.
The parameter list of the annotation org.hibernate.search.annotation.Field has changed (HSEARCH-710, HSEARCH-711). The annotation mixed the concepts of analyzing and storing of norms into a single index parameter (NO, TOKENIZED, UN_TOKENIZED and NO_NORMS). There was no option for analyzed indexing while storing no norms and the terminology was using the term tokenizing instead of analyzing. For this reason we changed the API and made the different choices more explicit:
@Field(index=Index.YES|NO, analyze=Analyze.YES|NO, norms=Norms.YES|NO, ...)
Another important API change is the ability to access an IndexReader by name (HSEARCH-903). For this purpose an new interface IndexReaderAccessor got introduced. It can be accessed via SearchFactory#getIndexReaderAccessor. The interface offers the following methods:
public interface IndexReaderAccessor {
IndexReader open(Class<?>... entities);
IndexReader open(String... indexNames);
void close(IndexReader indexReader);
}
Last but not least, you can now project on fields added by custom bridges (HSEARCH-890).
Make sure to read the Hibernate Search Migration Guide when trying to upgrade to Hibernate Search 4.
The release is available via the JBoss Maven Repository under the GAV org.hibernate:hibernate-search:4.0.0.Beta1 or via SourceForge. The latest documentation is on the JBoss Docs Server.
--Hardy
Hibernate Core 4.0.0.Beta5 has just been released. The complete list of changes can be found in JIRA release notes. Things are moving along with the main focus on the new metamodel and its integration into the Core engine.
The release is available from SourceForge in bundle form as well as from the JBoss Nexus repository under the org.hibernate groupId.
Enjoy!
| Showing 1 to 5 of 34 blog entries |
|
|