用于引导我的第一个生产scala项目的框架是什么？
我正在为生产应用程序首次涉足scala。 该应用程序目前打包为war文件。 我的计划是创建一个scala编译工件的jar文件，并将其添加到war文件的lib文件夹中。 我的增强function是通过Jersey公开的mysql支持的应用程序，并将通过HttpClient调用与第三方网站集成。 我知道如何通过普通的java做到这一点。 但是当我在scala中做这件事时，我有几个决定点，我正在pussyfooting。
- scala 2.7.7或2.8 RC？
- JDBC通过querulous这个API准备生产了吗？
- sbt vs maven。 我对maven很满意。
- 是否有一个用于HttpClient的scala惯用包装器（或者我应该像在java中一样使用它）？
我很想听听你对scala开始的评论和经验。
- 我会用2.8.0。 2.8中有太多有用的function。 此外，2.8正在接近最终版本。 如果你刚刚开始，为什么不从那开始呢？ FWIW，自从Beta1以来，我一直在使用2.8.0，在我每天使用的各种工具和库中。 虽然有bug，但还不足以让我回到2.7.7。 但是YMMV。
- 这不会让您的决定变得更容易，但是数据库访问还有其他可能性。 例如，我一直在使用SQueryL ; 我喜欢。 ORBroker是另一种选择。
- 如果您对Maven感到满意，那么请务必使用它。 就个人而言，我更喜欢SBT。 当我需要实现特殊的构建逻辑时，我获得了真正的编程语言的全部function。 同样有用，我不必处理XML配置文件。 （XML适用于数据，但对于人工编辑的配置文件来说，它是一种糟糕的格式。）
- 您可以尝试Databinder Dispatch。 请参阅此文章以获得精彩的概述。
- 如果您只是开始开发，Scala 2.8 GA可能会在您投入生产时提供。 即使不是，我会选择最新的2.8RC包而不是坚持2.7.7。 2.8不仅具有许多强大的function，而且还包含许多2.7.7错误修正。
- 如今，为Scala设计的生产就绪ORM并不多。 我可能会选择Lift Persistence ，因为Lift Framework背后的专业团队和友好社区。 但是如果你不想冒风险，你应该考虑使用旧的经过validation的Java ORM：Hibernate，JPA，iBatis（最近更名为myBatis）等。
- 你应该试试SBT吧！ 它与maven POM兼容，因此迁移到SBT对你来说不应该太痛苦。 使用SBT的好处：
- 它是专为Scala设计的，因此您可以免除为Maven维护无数插件的负担，使其与Scala始终如一地协同工作
- 您将能够在Scala中编写构建脚本（与XML相比，这是一种惊人的体验）
- SBT具有杀手级function – 持续不断 （构建，测试，部署）。 SBT监视您的代码，检测其更改时间，并触发操作（测试，重新部署等）。