Over the past few years there have been a few discussions on adding support for artifact generation based on Xmi. Most posts seem to point to AndroMDA for this task. However it seems to me that maybe something like this should be available in Hibernate Tools. AndroMDA seems to be a good tool but may be more than some want to bite off. Also, my guess would be that additions to Hibernate core / annotations would be available in Hibernate tools before a third party like AndroMDA would be able to have the functionality available.

We are currently looking at solving this problem, and looking at maybe contributing the necessary code or just using AndroMDA ( or ? ).

I want to generate POJO's based on a domain model and/or a physical ( ER ) model. I want to have sensible defaults but also the ability to change those defaults. I would like to have information in the model available in the export phase. I want to integrate this with Seam-Gen.

The complication of all of this is in all the different versions of UML and XMI and parsing this information to come up with a standard java object that can be then adapted to the Hibernate Configuration object. There are few libraries for doing this, none of which I am familiar enough with to include or exclude as a starting point. EMF has some capabilities, maybe core libraries in AndroMDA.

Are there any suggestions, opinions or general comments on this topic?

Having an exporter (or it should actually be an <xmiconfiguration> in Ant terms) that builds up a Configuration based on XMI is interesting.

Taylor already does something similar and I've been pushing the author behind it to do an "taylor2hbm" so we could all benefit from it - but it's not been done yet.

I would welcome any contributions in this and if it requires changes to the tooling to integrate well then I will be very open to adjust to it.

I really do not want to spend the time to write processing of XMI, so unless you have other suggestions, that leaves us with a couple choices. Netbeans MDR or Eclipse EMF. There was a library from Novosoft, but it does not appear to have been updated in a few years. I had read something about some limitations on EMF and tagged values, but I cannot seem to find the post again.

I am not a XMI expert but my research has come up with a few things. Tools implement there own version of the specification, so everything does not translate transparently. The same problem exists for profiles, users will want to import whatever profiles we create into their UML tool of choice.

It seems that the logical solution is to allow the configuration to take an XSLT file to use for transformation prior to the processing. It may also be appropriate at some point to house XSLT adapters for various tools or versions of XMI to be applied to the profiles.

We use Enterprise Architect from Sparx but I can also take a look at what the XMI looks like from ArgoUML or the Eclipse framework as an alternative.

At this point I cannot make any guarantees as to this contribution. I have been given the go ahead for some time, but I still need to discover the scope of the work. Anything you are able to do to help out is appreciated.

I spent some time today going through the different projects that I could find that do something similar to this. I think I understand why no one has yet contributed this. Most of the underlying libraries are really geared toward the end code generation. Parsing the different versions of xmi and uml specifications mixed with all of the different tools and their profiles isn't really worth the overhead when you are not also generating the code. Without the code generation you are really only creating a glorified version of the reverse engineering file in some form. You could get the same functionality from a decent XSLT transformation of the raw xmi.

Not to say that this could not be done, but do you really want the maintenance and support overhead? I think I would be just as happy if I could get the functionality from reverse engineering or a similar ( forward ?) engineering file. This may be a simpler approach. providing a means for users to contribute a transformation or adapter for specific tools may be more appealing. Of course my interpretation of the issues may be completely off base and I am open to any clarifications.


Does anyone have any thoughts, concerns or suggestions?

so what is different form generating code and generating some hbm.xml or other intermediate format ? i don't get that one ;)

the advantage of getting it into hbiernates model is that you don't have *dufferent* codegens.

That was really my point.

So the question is whether to use the reverse engineering file or something along the same lines.

Maybe it will help if I state some of the requirements I have. Some of these may already be available.


1.) Generation of artifacts in packages. -- This can be done with a naming strategy.

2.) Ability to set default mappings at the project level. -- Example: A project wants all timestamps to use Joda-Time, or all ids use a specified UserType.

3.) Ability to automatically discover inheritance of tables and the strategy to use.

4.) Automatic generation of enums based on column constraints. This may be simple yes_no type or specific values.

5.) Support generation of Proxy interfaces.

6.) Generate a portion of a project, if referenced entities already exist, create the mapping.

7.) Automatic generation of hashCode and equals.

8.) Discover and generate mappings for join tables.

9.) Generate annotations for validation.

There is a big difference in going from XMI (object/classes level) to mappings or go from JDBC (metadata/table level) to mappings.

I thought the XMI was what you wanted ?

What about just using the hbm.xml and get it to generate schema and code from which you can get XMI in other tools ? :)



eh - you set the default package name and it's done.



<type-mapping> and for anything more advanced use a custom revengstrategy.



where in the jdbc metadata would you find information to do that ?



should be doable - but again it requires some "magic".



why ? anyway it is doable.



what does that mean ? if it already exist create it again ?

currently it is bulk generation.



<meta attribute="use-in-equals">true</meta> for the properties you want to use. Anything that uses e.g. id's will generate non-valid equals/hashcode methods.



Same as #3



seam-gen does that already based on (some) schema data.

I am not quite sure yet what to do here, I am going to put some code together and see where it gets me.


1.) Generation of artifacts in packages. -- This can be done with a naming strategy.

The base package is not enough. If I have 100+ tables and performing a bulk generate, I do not want them all in the same package.


2.) Ability to set default mappings at the project level. -- Example: A project wants all timestamps to use Joda-Time, or all ids use a specified UserType.


3.) Ability to automatically discover inheritance of tables and the strategy to use.

The child will have a constraint on it's primary key which references the parent's primary key. Use sensible defaults and the discovery of a dicriminator column to determine the strategy.

Take a look at schema crawler. http://schemacrawler.sourceforge.net/


4.) Automatic generation of enums based on column constraints. This may be simple yes_no type or specific values.

Again the check constraints have this information.


5.) Support generation of Proxy interfaces.

Aside from being good coding practice to use interfaces, we have run into situations where we need to do an instanceof check on an entity retrieved through a relationship.


6.) Generate a portion of a project, if referenced entities already exist, create the mapping.

JIRA HBX-738

Regenerating everything is fine for a small project. However, what if you have 100+ tables/entities to generate? Any time saves is more time the developers aren't waiting for a build.

If you have multiple developers working in different packages, they have no need to generate completed code.


7.) Automatic generation of hashCode and equals.


8.) Discover and generate mappings for join tables.

I would say that if a table only consists of columns that are foreign keys to 2 different tables then it is a join table.


9.) Generate annotations for validation.

To go from XMI to XXX I would consider coding a plugin that replaced the JDBC reveng layer. Just as I had specialised the Oracle JDBC reveng it could just as well be reading XMI XML data sources. I have a blog entry I have half written to cover some of this. I just need to sit down finish it and send it to Max for his review and comments. I will try and look at it today.

Sounds great David.

What can I do to help out?

Hi David,

It is definitly possible to do and maybe the easiest one to do at the moment.

The downside is though that the XMI information will have to be "downgraded" to just being tables/column + maybe add some custom
revengstrategy to enhance it.

But feel free to look into it - will be fun ;)

[quote]8.) Discover and generate mappings for join tables.

Same as #3

In creating an example and looking at this, I believe you are correct to question this. You would need additional information to determine that this is a OneToMany as opposed to a ManyToMany. Hopefully that extra information can be carried from the xmi.

Agreed you would need a combination of XMIDriver and an appropriate revengestrategy. It would be fun though.