I've released version 0.2 of H8A8, a tool to use Java 5 annotations for hibernate mapping.

http://peelmeagrape.net/h8a8/index.html

This is a Java 5 alternative to xdoclet, or to Hibernate Annotations / EJB3. Hopefully some may find it useful.

regards,
Eoin.

You know, instead of spending all that time on a clone of existing functionality, a converter for HBM files that produces EJB3/HB annotated Java source code would certainly get more attention from Hibernate users.

We'd also be interested what features in Hibernate Annotations you find missing.

Hi, Christian,

Intresting idea! Is this your random thought or you guys have a plan for that?

No plans, but its pretty obvious, right? There are thousands of people out there who probably want to migrate at some point. And its not too difficult to write such a software.

Actually, hbm2java might do this already.

Yes, it can.

But not for H2 mapping files :)

it will actually do a pretty good job of it ;)

but in any case - hbm2java can do this, but we could need help to make it more complete (now it only handles the basic stuff)

So if someone wants to do that then please feel free to ask on how to contribute to that ;)

Skills needed: a craving for working with velocity templates and want to learn the small nerdy details of ejb3/hibernate mapping ;)

I wrote this code back in May, so I'm not sure whether the situation has changed, but the way it happened was:

• I was using xdoclet, and when I moved to Java 5 I found it didn't work
  
• So I tried out Hibernate Annotations which was in a pretty early release.
  
• I spent a lot of time trying to get it to work. Some of the problems I remember running into were:
  
  • not being able to specify uuid or custom primary keys ( http://opensource.atlassian.com/project ... wse/ANN-22 - marked resolved now)
  • Collections of Simple types (e.g. Set<String> - http://opensource.atlassian.com/project ... wse/ANN-19 )
  • I had to switch to an EJB3 way of mapping (i.e. learn the "small nerdy details" of hibernate -> ejb3 mapping). Since the EJB3 spec wasn't yet complete I didn't fancy tying myself into it

I didn't want to change my database schema, so I took the xdoclet generated hbm files and started maintaining them by hand.

After a while it occurred to me that it would be quite easy to generate xml from annotations (by annotating the annotations themselves with mapping info). So I coded it up (to cover the subset of the dtd that I needed), which took less time than I had spent trying to get Hibernate Annotations to work. (There's really only about a 1000 lines of code in there - the rest is annotations/metadata.)

I'm using this successfully in production. I figured since I'd done the work I might as well release it. H8A8 works well as an interim solution for me, and I'm in no rush to move to EJB3 (I'm very happy with hibernate and have no need for portability to another EJB3 implementation)

I quite like the idea of a converter for hbm files to generate the java annotations. I attempted the hbm->ejb3 migration by hand and it was not straightforward, so I guess automating it would be quite involved.
To do a migration tool for the H8A8 annotations would be fairly doable - most of the mapping between the annotations and xml is already captured in metadata. I've already migrated my projects by hand though, so I'm not in a rush to implement a converter for H8A8 unless I get a lot of interest in it.

regards,
Eoin.

well - the advantage of the hibernate metamodel is that it is used by both the hbm and annotation binder and thus includes exactly the information needed to do it automatically...

Of course. I assume the hbm model covers the entire metamodel, but from what I've seen the annotation binder doesn't yet do that. So the map from ejb3 annotations to the metamodel is not (in all cases) invertible.

Since (if) the hbm model covers the entire metamodel, then it also includes exactly the information needed.

When I was initially looking at Hibernate Annotations, I went through the code a bit to try and fix my problems. By nature of it's design it needs a lot of code like:

i.e. for each annotation / part of the metamodel, the binding has to be implemented by hand. This code is not reusable to implement the reverse mapping. If the reverse mapping was implemented it would have to be maintained separately.

My approach was to annotate my annotations, e.g.

can generate

from


and

means that

can generate


and adding new elements / attributes involves no coding.

Annotations and their properties map directly onto elements and attributes. So implementing the reverse map would be reasonably doable - and once implemented easy to maintain.

Maybe there is some analog to my approach whereby the hibernate metamodel could be annotated with the mapping needed by the hbm or annotation binder. If that was possible maybe the reverse mapping would work out cheaper to implement?

cheers,
eoin.

Your annotations are then driven purely by the xml schema which might not be the best way to specify it in annotations.

I like your solution for its generic transform back and forth - but generating from hibernate metamodel would be more valuable since we have specific "Binders" to handle the specific needs of XML, Annotations and JDBCMetaData ..... not possibly to do your trick without too much loss of specific functionallity (in my opinion)

/max

True enough - they probably aren't exactly how you'd design them, though they don't work out too bad. Though they're maybe closer to how Hibernate Annotations would have been designed without the EJB3 requirement?



Yeah - I'm not familiar with the metamodel or the binder code too much. It was a convenient hack for what I wanted to do, but probably isn't generally applicable.

e.

Another completely random thought - if you could read EJB3 annotations and generate XML (call it EJB3XML say), similarly to how I did - would it then be possible to convert that XML to hbm using XSLT? Or would the mapping from the EJB3 metadata to hbm/metamodel require other info from reflection on the classes? (EJB3 treating properties as persistent by default is one major difference in the mapping that occurs to me)

What I'm getting at is if there was code to take XML and generate the java source code for equivalent annotations then you could go HBM->EJB3XML->Source code and get the migration tool. (The problem with that is that not all HBM would be expressible as EJB3 i think).

But maybe writing the XSL for HBM->EJB3XML would be a lot of hassle. Maybe it'd just be easier to work through the HBM DTD and code the migration tool on an attribute-by-attribute basis.

eoin.

Yes, XSLT will seldomly be enough in these cases as it also need info from the classes - that is why hibernate metamodel is preferrable to use as a target/source for these conversions.

Please note that we have the migration tool in place for H3->Annotations, it just need to be made more complete to be truly usefull.

What could be interesting is a H2 to H3 hbm.xml transformation - for that XSLT should be enough (I think)

/max