【问题标题】:How to set up a multi-project SBT project with inheritance and shared dependencies如何设置具有继承和共享依赖项的多项目 SBT 项目
【发布时间】:2019-01-09 19:40:40
【问题描述】:

我想创建一个具有继承和共享依赖项的 SBT 项目。

使用 Maven 的 POM 文件,有Project Inheritance 的想法,您可以在其中设置parent 项目。我想对 SBT 做同样的事情。

xchange-stream library 在从父项目编译时使用 Maven 的项目继承来解决子项目依赖关系。

这是我对文件结构的想法:

sbt-project/
  project/
    dependencies.scala    # Contains dependencies common to all projects
  build.sbt               # Contains definition of parent project with references
                          # to subprojects

  subproject1/
    build.sbt             # Contains `subproject3` as a dependency

  subproject2/
    build.sbt             # Contains `subproject3` as a dependency

  subproject3/
    build.sbt             # Is a dependency for `subproject1` and `subproject2`

project1project2 可以在它们的依赖项列表中包含 project3,如下所示:

libraryDependencies ++= "tld.organization" % "project3" % "1.0.0"

这样,当subproject1subproject2 在其子目录中通过调用sbt compile 进行编译时,或者当父级:sbt-project 从主sbt-project 目录编译时,将编译subproject3并通过 SBT 在本地发布,或者以其他方式提供给需要它的项目。

另外,如何在sbt-project/build.sbtsbt-project/project 目录中的任何位置指定共享依赖项,以便在这些子目录中调用sbt compile 时,它们可以在subproject1subproject2 中使用?

以下示例无助于回答上述任何一点:

  1. jbruggem/sbt-multiproject-example: 使用递归 build.sbt 文件,但不共享子项目之间的依赖关系。

  2. Defining Multi-project Builds with sbt: pbassiner/sbt-multi-project-example: 对其子目录中的项目使用单个 build.sbt 文件。

  3. sachabarber/SBT_MultiProject_Demo: 使用单个 build.sbt 文件。

【问题讨论】:

    标签: sbt


    【解决方案1】:

    这样当subproject1subproject2 通过从其子目录中调用sbt compile 进行编译时...

    也许 Maven 旨在与 shell 环境和 cd 命令一起使用,但至少从 2019 年的 sbt 1.x 开始,sbt 并不是这样工作的。

    sbt 方式是使用sbt 作为交互式shell,并在顶层启动它。然后,您可以使用subproject1/compile 调用编译,或者使用project subproject1 切换到它,并在那里调用compile

    房屋插件

    通过创建自定义插件可以实现类似于父 POM 的功能。

    package com.example
    
    import sbt._
    import Keys._
    
    object FooProjectPlugin extends AutoPlugin {
      override def requires = plugins.JvmPlugin
    
      val commonsIo = "commons-io" % "commons-io" % "2.6"
    
      override def buildSettings: Seq[Def.Setting[_]] = Seq(
        organization := "com.example"
      )
      override def projectSettings: Seq[Def.Setting[_]] = Seq(
        libraryDependencies += commonsIo
      )
    }
    

    sbt-sriracha

    这并不完全符合您的要求,但我有一个实验性插件,可让您在源依赖和二进制依赖之间切换。见hot source dependencies using sbt-sriracha

    使用它,您可以为 project1project2project3 创建三个单独的 sbt 构建,它们都位于 $HOME/workspace 目录中。

    ThisBuild / scalaVersion     := "2.12.8"
    ThisBuild / version          := "0.1.1-SNAPSHOT"
    
    lazy val project3Ref = ProjectRef(workspaceDirectory / "project3", "project3")
    lazy val project3Lib = "tld.organization" %% "project3" % "0.1.0"
    
    lazy val project1 = (project in file("."))
      .enablePlugins(FooProjectPlugin)
      .sourceDependency(project3Ref, project3Lib)
      .settings(
        name := "project1"
      )
    

    通过此设置,您可以启动 sbt -Dsbt.sourcemode=true,它将选择 project3 作为子项目。

    【讨论】:

      【解决方案2】:

      您可以使用 Mecha 超级回购概念。在此处查看设置和文档:https://github.com/storm-enroute/mecha

      基本思想是你可以将依赖的sbt项目(与他们自己的build.sbt)组合在single root super-repo sbt项目下:

      /root
        /project/plugins.sbt
        repos.conf
      
        /project1
          /src/..
          /project/plugins.sbt
          build.sbt
      
        /project2
          /src/..
          /project/plugins.sbt
          build.sbt
      

      请注意,根文件夹中没有build.sbt! 取而代之的是repos.conf 文件。它包含子存储库的定义,如下所示:

        root {
          dir = "."
          origin = ""
          mirrors = []
        }
      
        project1 {
          dir = "project1"
          origin = "git@github.com:some_user/project1.git"
          mirrors = []
        }
      
        project2 {
          dir = "project2"
          origin = "git@github.com:some_user/project2.git"
          mirrors = []
        }
      

      然后您可以在各个项目中指定项目间、源级依赖关系

      有两种方法:

      • dependencies.conf文件
      • 或在构建源代码中

      更多详情请见docs

      【讨论】:

        猜你喜欢
        • 2015-12-12
        • 2014-01-19
        • 2017-08-09
        • 1970-01-01
        • 1970-01-01
        • 2019-12-19
        • 1970-01-01
        • 2013-06-15
        • 2018-03-20
        相关资源
        最近更新 更多