我正在开发一个项目,其中包含一系列spring XD的模块子项目,这些子项目碰巧对碰巧使用Scala的非模块子项目有一个瞬态依赖:
ext {
springXdVersion = '1.1.0.RELEASE'
moduleProjects = subprojects.findAll { project -> project.path.startsWith(':modules.')}
javaProjects = subprojects - (moduleProjects + nonJavaProjects)
}
configure(moduleProjects) { moduleProject ->
apply plugin: 'spring-xd-module'
}
project('core-dependency') {
apply plugin: 'scala'
// configuration/dependencies
}
project('modules.source.example') {
dependencies {
provided(":core-dependency")
}
}
// More modules bearing resemblance to modules.source.example
核心依赖最终设置在xd-container的类路径中,并以这种方式在运行时提供给模块。
不幸的是,似乎对于使用它的每个模块,核心依赖项都会被重新编译(由于它也包含了scala编译,因此特别昂贵)。这导致构建在30分钟以后运行,我想改进。有没有办法缩短构建时间?理想情况下,我不想重新编译核心依赖,但我不知道如何实现这一点,因为bootRepackage似乎负责为每个模块触发它。我也尝试过其他技巧,例如并行性,但这样做到目前为止只能冻结我的系统。我正在使用gradle 2.1。
我应该注意,gradle配置文件报告指出,对于每个模块,大部分时间沉没在configureModule步骤中,根据spring-xd repo,该步骤如下所示:
project.task('configureModule') << {
project.configurations.provided.resolvedConfiguration.firstLevelModuleDependencies.each {
excludeTransitiveDependencies(project, it)
}
}
答案 0 :(得分:0)
scala依赖性来自SpringXD中的Spark streaming
集成。我们正在努力消除对spring-xd-dirt
的依赖关系,并将其从模块中提供:
https://jira.spring.io/browse/XD-2857
您依赖的具体非模块子项目是什么?如果是spring-xd-module
,那么您可以尝试1.2.0.M1,我们已将火花依赖性从spring-xd-module
移至spring-xd-dirt
。
答案 1 :(得分:0)
在configureModule步骤期间,将评估所有项目的传递提供的依赖关系,核心依赖关系是。减速是由核心依赖依赖的绝对数量引起的,并且通常需要扫描。由于我们希望避免configureModule扫描核心依赖项,因为它太耗时,而且我们知道它需要从模块fatjars中排除,所以适当的操作方法是从提供的配置中删除核心依赖项,并简单地把它从脂肪罐中排除。
为此,gradle构建脚本的修改如下:
ext {
springXdVersion = '1.1.0.RELEASE'
moduleProjects = subprojects.findAll { project -> project.path.startsWith(':modules.')}
javaProjects = subprojects - (moduleProjects + nonJavaProjects)
}
configure(moduleProjects) { moduleProject ->
apply plugin: 'spring-xd-module'
configurations{
core
compile.extendsFrom(core)
}
configurations.exported.exclude module: 'core-dependency'
}
project('core-dependency') {
apply plugin: 'scala'
// configuration/dependencies
}
project('modules.source.example') {
dependencies {
core project(":core-dependency")
}
}
// More modules bearing resemblance to modules.source.example
“核心”配置本质上是第二个“提供”配置,它不会被configureModule任务拾取,从而避免浪费时间评估它。它也被排除在“导出”配置之外,其配置内容决定了bootRepackage构建的胖jar中的内容。