首先我要说的是，是的，我对Maven已经感到厌烦了。自从我决定将Hibernate的构建工具从Ant切换到Maven以来，这2年里，我认为Maven并没有让构建过程变得更加简单。相反，实际上情况是相反的。在此之前，实际上并没有其他选择。当时ant/ivy组合刚刚开始受到关注。更不用说我还喜欢Ant提供的构建约定这个概念了。
抛开错误不谈，我大部分与Maven在处理Hibernate方面的问题都源于Maven假设所有项目都是可以独立发布的。这里的问题在于，这也扩展到了子项目或所谓的“模块”。对于Hibernate来说，决定使用子项目纯粹是为了隔离对可选Hibernate功能的各种依赖。例如，我们有一个专门处理c3p0作为JDBC连接提供者的子项目。Hibernate对c3p0构件的依赖在这个模块中被完全隔离。所以作为用户，你可以简单地告诉maven你正在使用hibernate-core和hibernate-c3p0，并设置正确的传递依赖。我并没有设置这些子项目以便在某个时候独立发布hibernate-c3p0。在我看来，这样做只会带来混乱。即使hibernate-c3p0中的类没有任何变化，我也更愿意将其升级到新的标准化版本。
总之，这个假设有哪些问题呢？首先，我不能简单地“切换目录”进入子项目目录并构建它，并期望Maven自动为我构建这个子项目所依赖的其他项目。例如，我不能切换到hibernate-c3p0项目目录并运行'mvn compile'，并期望Maven首先为我编译hibernate-core项目，尽管hibernate-c3p0依赖于它。这听起来可能不是什么大事，但Hibernate是一个庞大的项目，有14个产生jar文件的项目（更不用说众多支持项目，如文档和分发构建器）。不得不在所有这些不同的项目中“切换目录”只是为了编译Maven已经了解的依赖关系图，这似乎很愚蠢。但是，Maven必须这样做，因为这是对项目独立性
的假设。
另一个问题与臭名昭著的发布支持不佳有关。每次我尝试使用Maven的发布插件进行Hibernate发布时，它都会给我带来麻烦。事实上，它只是导致Hibernate 3.5.0.Beta-1发布延迟了3天。我知道发布插件只是围绕一些你可以自己运行的mvn命令的包装器（实际上这就是我最终结束3天的3.5.0.Beta-1发布马拉松的方式）；问题是又回到了Maven对多项目构建的支持
。发布插件是唯一目前提供对整个子项目所需的大量版本声明管理的支持的插件。所以当你发布包含多个子项目时，你有两种选择：（1）使用发布插件或（2）（a）手动更新pom版本（b）提交（c）r标签（d）手动更新pom版本（e）提交（f）检出标签（g）执行mvn deploy。如果发布插件的版本管理
功能可以单独使用那就太好了。
我简要查看的其他构建工具有（1）gradle、（2）buildr和（3）simple-build-tool。有人有这些的实际经验，或者有其他我们应考虑的建议吗？
