显然，我是在说Scala项目。在我们讨论这个话题时，SBT的稳定版本是0.13，我想再过几年，本文提及的问题会一一得到解决，从而让SBT成为一个真正成熟强大的构建工具。

在我们目前开发的系统中，有一个基于AKKA的组件，使用Scala语言进行编程。绝大多数情况下，构建Scala项目首选的工具是SBT，作为新一代的构建工具，SBT吸收了众多前辈的优点，简单易用，能够满足基本的应用场景。

但是SBT确实还不够完善和强大，在实际的项目构建中，当面临一些相对复杂的场景时，会显得比较无力。其中最为我们不能接受的是面向多环境的构建。尽管社区提出过一些解决方案，例如http://stackoverflow.com/questions/17193795/how-to-add-environment-profile-config-to-sbt ， 但是这个方案的缺陷在于对于每一套环境都要提供全套的配置，即是它们在多数据环境中的值是一样的。实际上这个问题的本质原因是SBT尚没有类似Maven那样在构建时基于某个配置文件对一些变量进行过滤和替换的Resource+Profile功能，这是很重要的一个需求。

就打包方面，我指的是构建一个包含命令行工具、配置文件和各种Lib的安装包，SBT的sbt-native-packager确实非常强大，令人影响深刻。同样，在面向不同环境的前提下，打包不同用途的package时，sbt-native-packager的灵活性还有待检验。例如，基于我们过去的最佳实践，面向每一种环境，我们尝尝会利用maven-assembly-plugin构建两种package，一种是包含全部产出物的标准部署包，一种是仅仅包含每次构建都有可能发生变化的文件，例如项目自身的jar包和一些配置文件，我们把这种包称为最小化的package，这种package会用于日常的持续集成的部署，它的体积很小，在网络带宽有限的环境里，它会大大节约部署时间。在这方面，我不能确定sbt-native-packager能否完美实现，因为在遇到前文提及的问题时我们已经放弃了对sbt-native-packager更深入的研究，这里提出打包问题，也是在分享我们的最佳实践。

回到Maven，我必须承认我是Maven的忠实拥趸，在过去数年的开发工作中，Maven满足了我们各式各样的构建需求，从没有让我们失望过，它的约定大于配置的思想和丰富的周边插件真正实践了：Make simple things simple, complex things possible!

即便如此，在我刚刚开始我的Scala编程之路时，我还是坚定地拥抱了SBT，社区基于Scala的开源项目也多是基于SBT构建的。但是当一个项目进入真正的开发流程时，SBT表现的还不够强大，对比Maven上的种种最佳实践，不由得让我们回归Maven，但是这并不代表我们会在Maven上停滞不前，实际上我们对SBT抱有很大的期望，只是它需要时间变得更加强大。在未来某个合适的时机，我想我们会再次回归SBT。

本文原文出处: http://blog.csdn.net/bluishglc/article/details/57890873 转载请注明出处。