Community
Participate
Working Groups
JPA specifies support for multiple mapping files in a persistence unit, each of which may be named anything (though the default name is orm.xml), so long as they are referred to by name in the persistence.xml file. ((example)) <persistence> <persistence-unit name="MyPU"> ... <mapping-file>META-INF/orm.xml</mapping-file> <mapping-file>META-INF/orm2.xml</mapping-file> ... </persistence-unit> </persistence> Currently Dali supports only files named "orm.xml", mainly because the WTP ArtifactEditModel framework only supports retrieval of EMF resources that are tied to file names, not to file content (we have registered orm file content through the root element content describer, so we have a file content that reaches beyond the file name.) Currently this work is blocked by bug 152461.
I created my own mapping XML form the XML schema catalog (New -> Other… ->XML). After that I added it from the persistence.xml editor, which recognized it. Unfortunately as result I received in the Problems view the following error message: Mapping file "META-INF/my_orm.xml" cannot be resolved I suppose that the reason is this issue? In addition I added a comment to the bug 152461
Yes, it's exactly that issue. The error is because we can't build content for the file in question, and that's because of the WTP resource registration/loading mechanism. We're exploring the possibility of using a different mechanism (from the ArtifactEdit mechanism) to build file content, and so thereby avoid the file name restriction on WTP files, but it would be after M6 that we'd be able to add this. If it's not possible to do in a clean and timely (and approved) fashion, it's likely we'll have to defer multiple mapping file support (and therefore "differently named" mapping file support) for our next release.
Re-targeting for M7, but it is possible that the amount of changes needed to make this work will be too much for the M7 window. Hopefully we can do it, since this is a very important feature.
I am sad to say that this is being deferred to the next release due to the fact that it is too late to make the changes necessary to enable this. It is a major limitation in our tooling.
This looks good to be considered resolved and fixed for 2.1M3. If there are minor issues (validation order, resource type mixing issues, etc.) those can be tracked in other bugs, and should be resolovable as bugs, not major features.
Marked as fixed.
verified in current code
