在LinkedIn,我们一直在评估最好的开发框架和工具来开发伟大的产品。11年的历史中,我们使用过很多前端web框架-如Grails、Frontier(LinkedIn内部的web框架),最近是:Play!我们喜欢Play,并热情地在公司内部推行起来。于是我们用Play进行了整合和扩展。现在我们正在评估哪个构建系统(build system,下同)更好用。
这篇文章介绍了用在Play中用Gradle来支持开发,及Gradle的目前状态和它的初步特性的演化。我们希望Play社区提供更多反馈以帮助Gradle类软件的开发。能够给Sbt和Gradle开发Play应用将提供更多的自由度和多样性。
在LinkedIn,我们用代码仓库管理公共API和服务,每个这种仓库我们给它取了个名叫 Multiproduct,每个Multiproduct通过独立的Ivy来组织,默认的名称是com.linedin。LinkedIn的部分代码已经开源了,如databus。
用Multiproducts来组织代码的结果是,它们都是多工程的构结构,每个Multiproduct有10个或100个工程,同时每个工程又有多个 构件(artifacts,下同)。
在LinkedIn,我们的Play应用在classpath路径下有超过500个jar包,这意味着全依赖解析的话需要处理至少500个节点。但依赖解析重度依赖于冲突解决的规则(导致效率低)。我们不在构件(如jar)层解析版本,而是在Multiproduct(或Ivy组织)层处理,这样可以保证同一个Multiproduct内全部构件版本是一致的。
例如,工具类util Multiproduct,我们有3个不同的模块,com.linkedin.util:foo, com.linkedin.util:bar, com.linkedin.util:baz。每一个模块可能有一个或多个构件,一般的冲突解决办法 可保证所有模块只有一个版本,但不同模块间的版本(本例中的"com.linkedin.tuil:foo", "com.linkedin.util:bar", and "com.linkedin.util, baz")仍可能不同。我们自定义依赖处理器将确保同一个Multiproduct中的所有构件是同一个版本。
Play默认的构建工具是SBT,Play与SBT在技术上是解耦了,但底层仍有很多未分离。当我们开始开发Play应用时,很快就遇到了SBT扩展性方面的挑战,而且很依赖于Apache Ivy库,某个应用的依赖解析需要5-10分钟,一个框架工程呢,就要花30分钟以上。
过去一年,LinkedIn跟Typesafe合作来提升SBT的扩展性,现在还在继续,然而,同时,我们感觉到评估下其它的构建工具也是值得的。
LinkedIn已经使用Gradle有3.5年了,到处都有gradle的影子,从小项目到单个Multi-product构建了近4000个工程,而且2015年的gradle还带了许多激动人心的新特性。
除了以上,我们相信整合两者对双方都很有价值,跟Gradleware 一起我们开始研究如果让它成为现实。2015年上半年,我们将注重整合的实现和测试,已经完成 3个里程碑 了。
让Gradle与Play的插上电,开发者可以用gradle构建一个具有Play全部特性的应用。
特性包括:
编译Java和Scala源码
编译路由
编译模板
编译资源/配置文件
支持CoffeeScript, LESS/CSS, JavaScript
使用这个构建管道,Play应用可以用 gradle run 或 gradle start 启动,或用 gradle stage 或 gradle dist 来发布。
有了这个能力我们就可以全面的测试Play的构建系统的性能和可扩展性了。
提示:这个里程碑里 持续模式(continuous mode) 和 热加载(hot reload) 不支持。
开发应用时能够热加载将是最令人愉快的Play特性。
自动化之前手工打包处理是一个伟大的主意,我们热切希望能加到gradle里。里程碑2将介绍Gradle的“观察者”模式,这跟SBT的持续模式(continuous mode)相同:gradle --watch run。
Play也可以当浏览器刷新时自动重新构建,这是通过Play的BuildLink接口实现的,这个里程碑将包含这个特性。
如果你熟悉Play可能已经注意到了缺失了一个严重的特性:Scala的交互功能 REPL!别急....这是里程碑3的一部分,将允许你在控制台与类(classes)进行交互。
还有文档,跟Specs2 整合了, 还有Scala的代码也优雅的集成了。为了让这些一起启动起,你需要一个适当的Gradle基础平台,就像你之前用activator一样。
想了解更多?可以参考这里。
该里程碑的特性已经完成了,你可以下载最新版本尝试下。下载包里有二进制文件、源代码文件和例子工程。解压缩后加“bin”路径加到你的环境变量。
Play的例子在 “samples/play” 目录。
基本的
基本例子 build.gradle 文件演示了Play插件声明及仓库需求配置,依赖块展示了如果定义第3方类库,'play' 配置提供了统和运行依赖,'playTest' 提供了测试时的依赖定义。
高级的
高级例子 build.gradle 展示了如果配置成 Play/Scala 版本。
Multiproduct:
这是标准的Gradle multiproject 构建配置,根目录包含了Play主应用,3个子模块在modules目录下,admin和user子模块在在各自文件夹里,utile是一个java 类库。settings.gradle 文件连接了3个子工程,主工程build.gradle 描述了3个子模块各自的依赖。
你可以尝试执行以下任务:
gradle :assemble
:构建 jar 和 assets
gradle :runPlayBinary
: 构建和运行应用在开发者模式
gradle :check
: 执行测试用例
gradle :stage
: 构建和发布 image, 与启动脚本一起
我们比较了Gradle和Activator(sbt)两个方式的构建时间。
用来比较的工程
Basic - 一个简单的Play工程, play-scala模板设为activator.
Multiproject - 构建在gradle的multiproject的Play例子工程,a multiproject build based on the gradle’s,例3也是util的子工程.
测试方法
所有依赖库已经下载到本地gradle和ivy缓存里.
测试任务"dist "将生成最终发布tar包,将测试整个构建和发布流程,同时围绕着依赖解析、编译、打包执行。
Gradle是串行执行,在 vanilla sbt 使用时 configure-on-demand 和 daemon 启用 .
Clean-build: 展示了从一个干净状态的完整打包处理流程。
No change: 没作任务改变返回 “dist” .用来测试构建配置和更新有多快。
Incremental:改了一行让根Play工程依赖了java或scale子工程来模拟典型的流程。
从以上可以看出,Gradle构建除了1个差一些外都胜出了,不管是没有或小修改都很好,这正是我们期望的。http://app.csq.im
基本依赖解析性能评估
我们对依赖解析的性能更加感觉兴趣,所以我们只想比较解析所有依赖要花多久,对 activator/sbt
备注
1.Gradle的“依赖”解析任务不仅仅是解决依赖问题,实际上还打印出了4个子工程的依赖树
2.Gradle的依赖解析处理时间是通过内置的分析工具报告的
从上面的结果可以轻易的得出结论 Gradle的原生依赖解析引擎快过activator/sbt使用的 Ivy引擎 10倍以上。那就是我们为何将java工程构建在Gradle之上的原因。
我们仍努力将之前需要5-10分钟的的activator/sbt项目用Gradle进行重构,我们期望更好的结果!
译者
http://my.oschina.net/u/1263162/blog