There's a JIRA issue [HBX-364] suggesting that the tools support Hibernate mapping file extensions other than .hbm.xml. I was looking into implementing this in the eclipse plugins and have a few questions.

My suggestion is to give the user control over the extension used. Anyone think this is not the right approach? Should the scope be workspace (an Eclipse preference) or project (an Eclipse project property)?

One place the extension is used in in the Console, when you add a mapping file to a configuration. Is there any other use of the extension that should be controlled by the preference or project property?

no, it should just be controlled by which files are configured as the hbm.xml content type.

You mean the Hibernate Mapping Content-Type? I thought that couldn't be set to *.hbm.xml because Eclipse doesn't currently support extensions with more than one . in them.

yes, so the bug needs to be fixed in eclipse ;) (and content type is not dependent on name patterns, it is dependent on the content)

and you do know you can just use a hibernate.cfg.xml to load these non-compliant-named files, correct?

In other words i don't want to add alot of additonal configuration code to the ui which can be handled in so many other *standard* ways or will be fixed when someone fixes the limitations in the underlying platform.

The thing I can be convinced to accept is a toggle button on the dialog with the xml selection that will allow you to select all *.xml files or maybe allow you to open a resource finder dialog where you can enter any filename to add.

My understanding of the content type association is that it's a two-step process: first check the file extension and then check with all describer classes associated with that extension. Each describer classes looks at the file content, e.g. checks the dtd or whatever.

The significance of the use of hibernate.cfg.xml here is that it provides a reasonable workaround. And given that a workaround exists, there's no urgent need to add extra stuff in the UI. I can go along with that, although I should point out that adding a new user preference is no more work than the other proposed changes to the configuration wizard.

there are no preference ui now, so it will definitly be more work ;)

I just like it to be as simple as possible to maintain and use.

Actually I already implemented the preference item, since I wanted to learn how to do that. It turns out that there's a wizard that generates the Java code defining the preference. All you have to add is one entry to the plugin.xml and then change one place to retrieve the preference value instead of using the hardcoded "hbm.xml' string.

I don't mind throwing that stuff away since it was a learning exercise. My point is don't back off from using a preference because it's too much work (although it does become one more thing to understand when maintaining the code). Deciding a preference isn't right from a UI design standpoint is another matter of course.

" Deciding a preference isn't right from a UI design standpoint is another matter of course." - yup, but still the thing that I find most important