我有一个SBT Scala多项目,结构如下:
multiprojectRoot
project/SharedProjectBuildCode.scala
project1
src/sourceFiles
project1-build.sbt
project2
src/sourceFiles
project2-build.sbt
projectN
src/sourceFiles
projectN-build.sbt
multiprojectRoot/项目/SharedProjectBuildCode。包含多项目定义,使用dependsOn来创建对本地项目的依赖。例如:
lazy val project2 = Project( ... ).dependsOn(project1)
multiprojectRoot/project2/project2-build。包含给定项目的设置和依赖项。例如:
name := "project2" libraryDependencies ++= Seq( ... "my.company" % "project1" % "1.0" )
对project1的第一个依赖是用SharedProjectBuildCode的dependsOn声明的。第二个是在独立的project2-build上创建的。SBT构建定义文件。
因此,project2定义包含:
- 对project1或 的模糊依赖
- 对project1的双重依赖
我们希望保持这个项目结构,因为它最适合我们当前的工作流程:
- 独立的。sbt文件为持续交付服务器上的每个项目提供独立的部署目的。
- 多项目。scala文件使用dependsOn来促进开发,允许我们避免诸如连续publishLocal之类的事情。
我们需要以某种方式控制这种依赖关系的模糊性。你能帮我吗?
我认为你应该在SharedProjectBuildCode.scala
lazy val root = Project(id = "Main-Project",
base = file(".")) aggregate(project1, project2,..)
lazy val project2 = Project(id = "project2",
base = file("project1")).dependsOn(project1)
...
并且不需要在构建中添加作为依赖项。sbt了。
我能够通过使用SBT提供的构建文件加载规则来控制在每个用例上加载哪个依赖集。
当您从给定的根目录加载SBT时,它查找*。根目录上的SBT文件,也用于*。在根/项目目录下安装Scala。如果您有一个多项目构建,那么它也会读取的定义。在子项目中遇到的SBT文件,但它不会使用project/。子项目上的Scala文件:
。SBT构建定义
多项目构建
所以,我改变了我的多项目构建如下方式:
multiprojectRoot
project/SharedProjectBuildCode.scala
project1
src/sourceFiles
project/DeploymentOnlyCode.scala
project1-build.sbt
project2
src/sourceFiles
project/DeploymentOnlyCode.scala
project2-build.sbt
projectN
src/sourceFiles
project/DeploymentOnlyCode.scala
projectN-build.sbt
这样,根据用例,我从多项目根目录或项目内部目录运行SBT:
- 开发:SBT从multiprojectRoot目录运行。它利用了多项目构建的优势(例如使用dependsOn和避免publishLocal)。
- 生产:SBT从具体的项目目录中运行,例如multiprojectRoot/project2。它允许将项目作为独立构建,将所有依赖项显式地置于外部(对于在生产、持续集成服务器上声明一系列依赖项非常有用)。
现在,一个项目有3个代码实例,这些代码实例为最终构建聚合了它们的属性:
- multiprojectRoot/项目/SharedProjectBuildCode。scala:包含与多项目构建相关的本地依赖和其他代码。
- multiprojectRoot/project1/project1-build。sbt:包含项目构建属性,用于项目的多项目和独立构建,例如始终外部的名称或依赖项。对于相同级别的其他多项目项目也应该这样做,以显式地将其视为外部依赖工件。
- multiprojectRoot/project1/项目/DeploymentOnlyCode。scala:包含仅在独立构建时考虑的构建属性。如果需要定义特定于部署的属性,也可以在其他子项目上执行相同的操作。
这也提供了对如何构建项目的最大控制,是否为可发布工件,并处理仅与给定项目相关的源代码,作为一个完整的和独立的部分。