We're updating the issue view to help you get more done. 

Develop Hibernate mapping XSD extending the JPA mapping (orm) XSD



Per the subject, develop an XSD that allows mixing JPA orm.xml elements and Hibernate-specific features. It is important that this "unified" XSD be able to validate spec-compliant mapping documents (aside from considerations listed below).

hbm.xml as a format will be deprecated. There is work underway on a transformation from hbm.xml format into this new unified mapping format. This transformation will be available as a build time tool. Additionally, this transformation will be available on-the fly for the time being (though certainly adds overhead to Metadata building - startup). See for additional details.

Ultimately this allows us to internally have a singular view of mapping metadata via Jandex as a merging between annotations and XML mapping. This is actually mandated and specified by JPA in terms of standard annotations and the standard XSD. BUt this work will also allow "Hibernate extensions" to become part of this equation.

Spec Deviation Considerations

The main deviation is in regards to /entity-mappings/entity@class being required per the JPA XSD. We need to deviate from that to support dynamic models (map mode atm).

Usability considerations

Some things to consider from a usability PoV as I develop this..

How to handle wrapping features?

Consider defining a natural id. In hbm.xml this is done sort of like a <component/> (because a natural id is internally handled as a dynamic composite):

1 2 3 <natural-id> <property .../> </natural-id>

In terms of a direct translation into unified XSD this would look like:

1 2 3 <natural-id> <basic .../> </natural-id>

Not sure that is the best format for specifying a natural id here. So far this is exactly how I have defined it in the XSD, but want to consider better alternatives. I have considered an attribute on the property elements:

1 <basic ... naturalId="true" />

But that is troublesome when the property elements are used in contexts other than at an entity level (composite map key, etc). Having a wholly separate element to contain natural id information for the entity would work, but would lead to duplicating the property names:

1 2 3 4 <natural-id> <defined-by/> // lists attribute names // plus have caching strategy info </natural-id>





Steve Ebersole


Steve Ebersole

Fix versions





Suitable for new contributors


Requires Release Note


Pull Request