但是，如果从Developer's Notebook一书中的下载源代码开始，就至少得有一项技巧才可以让编辑器工作。在下载的文件中，映射文档的扩展名为“.hbm.xml”，而只有以“.hbm”结尾的文件才能调用编辑器。理论上，可以在Eclipse中配置扩展名映射，以便使具有这两种扩展名的文件都能使用插件的映射文档编辑器，但是我无法使其生效，而且我注意到支持论坛上有人面临着与我相同的问题。所以，至少目前最好的做法就是重命名文件。（如果您坚持使用基于Ant的标准代码生成，请确保更新build.xml中的codegen目标以使用新的扩展名。）
在我把Track.hbm.xml重命名为Track.hbm之后，它在Package Explorer中的图标就更新为Hibernate徽标，而默认的编辑器则变为插件的编辑器，如图23所示。由于某种原因，其他的Hibernate Synchronizer选项（如图17所示）对于其中任意一种扩展名都是可用的，但是编辑器只对较短的版本可用。
图23. Hibernate映射文档（扩展名为“.hbm”）的上下文菜单
编辑器为映射文档中添加的所有元素都提供上下文相关的自动完成支持。图24显示了一些例子，但是屏幕截图无法真正捕捉到该特性的深度和有效性。我强烈建议您安装插件并使用它。您很快就会看到它在处理映射文档方面是多么有用。
图24和25.映射文档编辑器中的完成辅助功能
如图26所示，大纲视图提供了一个关于类层次结构、被映射的元素、指定查询以及映射文档中的各种元素的图形化视图，还提供一个菜单，其中有一些向导可以帮助创建新的属性。
|
|
|
图26和27. 映射编辑器的大纲视图和“Add property”向导
编辑器中的上下文菜单还提供一个Format Source Code选项，可以使用它来整理和重新构造文档。这个编辑器中已经有了很多灵巧和有用的特性，看它们如何发展也是一件有趣的事情。惟一使我感到不满的是（并不是什么大问题），当完成XML属性时，这个编辑器用来帮助管理引号的方法与JDT在Java代码中使用的方法完全不同。在它们之间来回切换会把人弄迷糊。（您需要一些时间适应JDT的工作方式，但是一旦您开始信任它，它就会变得魔力无穷。）
生成数据库模式
尽管我的第一印象是所有内容都来自映射文档，但是Hibernate Synchronizer目前不支持从映射文档创建或更新数据库模式。支持论坛上已经提出了相关的请求，所以如果将来看到这些特性，我肯定不会吃惊，因为提供这类支持并不很困难。目前来说，如果要从映射文档开发数据库，就必须使用像Hibernate: A Developer's Notebook书中这种Ant驱动之类的方法。此外，下面描述的Hibernator插件支持在Eclipse中进行模式更新。我可能要研究一下是否可以同时安装这两种插件。
我希望本文能够让您清楚地了解该插件所提供的功能。无论如何，我没有涵盖它的所有功能，所以如果您有兴趣，可以去下载它然后自己进行探索。
权衡
毫无疑问，可以使用Hibernate Synchronizer来完成一些灵巧的工作。是否要在我自己的Hibernate项目中使用它呢？这样做有优点也有缺点，很可能直到实际采用Hibernate来代替我们正在使用的自己开发的（且过分简单的）轻量级O/R工具时，我才会做出决定。这是一次意义相当重大的改动，而我们把这次改动推迟到了由于其他原因进行架构变换的时候。下面是对我的决定起着重要作用的一些因素。
正如我们在安装小节中所谈到的那样，在许可证方面还存在着一点问题。插件的论坛中有此方面的讨论。当前的许可证基于对GNU GPL的定制修改，这次修改删除了所有源代码共享方面的条款，但是试图保留“copyleft”保护的其他方面。关于这样做的合法性仍然存在一些问题，而作者正在寻求另一种解决办法。很清楚，目的是要保护插件，而不是阻止其他任何项目使用该插件生成代码，但是有必要仔细阅读当前的许可证，看一看其目的是否已经达到，或者您是否仍然冒着很大的风险。
同一讨论表明，作者原来是以开源的形式发布插件的，但是又临时收回了这一决定，因为他觉得它还不够完美以用作一个优秀的范例。接着，他与一些莽撞的人通过一些非常不愉快的邮件，这使他不愿再共享源代码。当然，他有权决定是否与我们共享源代码。该插件对于整个世界来说是一份大礼，而作者并不欠我们什么。但是我希望他能与其他用户进行足够的正面交流，这样就能坚定他原来共享源代码的想法。我真的认为能够看到我使用的工具的源代码是一件很有价值的事情，不仅因为这是一个很好的学习机会，还因为这意味着，如果需要的话我可以立刻修复一些小问题。作者在解决用户的问题方面始终很热心，响应也很快，但是一个人无法维持一个社区，因为我们都有繁忙、筋疲力尽和心烦意乱的时候。
Hibernate Synchronizer使用它自己的模板和机制来生成数据访问类，这既有优点也有缺点。优点是可以获得比Hibernate的“标准”代码生成工具更多的功能。可以使用数据对象的一个自动生成的子类，并在该数据对象中嵌入业务逻辑，而无需担心重新生成访问代码时这些业务逻辑会被改写，这也是一个不错的特性。插件生成的使很多简单的场景更简单的类还提供了其他的优点。
另一方面，这还意味着，当Hibernate平台增加一些新的特性或者做了改动之后，Hibernate Synchronizer生成的代码就有些滞后于Hibernate了。在对Hibernate不常使用的模式的支持方面，插件代码也存在bug：它的用户群很小，一个人就可以让它保持更新。您可以在讨论论坛上找到这种现象的证据。
和很多事情一样，潜在的优点是否超过风险要由您来决定。即使不使用代码生成器，您也会发现映射编辑器非常有用。如果您只想使用编辑器的自动完成和辅助功能，可以关掉自动同步选项。
如果您使用过该插件，并且发现它很有用，我建议您联系其作者，表达您的谢意，并考虑捐出一些资金来帮助支持它的未来发展。
其他插件
迄今为止，我还找到了另外两个也提供Eclipse中的Hibernate支持的插件。（如果您还知道有其他的插件，或者将来遇到了这样的插件，我很愿意知道它们。）或许将来我还会撰写有关这些插件的文章。
HiberClipse
HiberClipse插件看起来也是一种非常有用的工具。它似乎适用于数据库驱动的工作流，在这个工作流中，已经有了一个数据库模式，而您想构建一个Hibernate映射文件和Java类来使用该模式。这是一种很常见的场景，如果您发现自己面临着这样的难题，我强烈推荐您使用这个插件。它提供了一项非常酷的特性：在Eclipse中为所使用的数据库提供图形化的“关系视图”。（我应该指出，如果您想从一个现有的数据库模式开始，Hibernate Synchronizer也会有所帮助的。它的New Mapping File Wizard可以连接到您的数据库，并基于所发现的内容构建映射文件。）
图28. Hibernate Synchronizer的映射向导
Hibernator
最后一个，Hibernator似乎倾向于另一个方向，即，从Java代码开始生成简单的Hibernate映射文档，然后让您从映射文档构建（或更新）数据库模式。它还提供在Eclipse中运行数据库查询的能力。在这3种插件中，它所处的开发阶段似乎最早，但是已经值得关注了，特别是因为它的开发者是Hibernate开发团队的成员。