Контроля нагрузка зависимости двусмысленность от SBT несколько проектов

Question

У меня есть 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.scala: содержит определение несколько проектов, которые используют dependsOn для создания зависимостей от локальных проектов. Например:

  lazy val project2 = Project(
      ... 
  ).dependsOn(project1) 
  

• multiprojectRoot/project2/project2-build.sbt: Содержит настройки и зависимостей для данного проекта. Например:

  name := "project2" 
  
  libraryDependencies ++= Seq(   
        ... 
        "my.company" % "project1" % "1.0" 
  ) 
  

Первая зависимость к project1 объявляется с dependsOn на SharedProjectBuildCode.scala файл и второй создан на отдельный файл определения сборки project2-build.sbt.

Таким образом, определение project2 содержит либо:

• неоднозначная зависимость к project1 или
• двойной зависимости к project1

Мы хотим сохранить эту структуру проекта, потому что является лучшим для наш текущий рабочий процесс:

• Независимые .sbt файлы служат автономным развертыванием nt для каждого проекта на нашем сервере непрерывной доставки.
• Multi-project .scala file with dependsOn используется для облегчения разработки, что позволяет избежать таких вещей, как непрерывный publishLocal.

Мы должны иметь контроль над такими неопределенностями зависимости каким-то образом. Вы можете мне помочь?

Answer 1

Я смог контролировать, какой набор зависимостей загружен в каждом прецеденте, используя правила загрузки файлов сборки, предоставленные SBT.

При загрузке SBT из данного корневого каталога он ищет файлы * .sbt в корневом каталоге, а также для * .scala в каталоге root/project. Если у вас многопроектная сборка, то она также считывает определения файлов .sbt, которые встречаются в дочерних проектах, но не будет использовать проект/.Scala файлы на дочерних проектов:

.sbt build definition

Multi-project builds

Итак, я изменил мой мульти-проект построить следующим образом:

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. Он использует преимущества создания нескольких проектов (таких как использование dependOn и избежание публикацииLocal).
• Производство: SBT запускается из справочника конкретных проектов, например multiprojectRoot/project2. Он позволяет строить проект как автономный, имея все зависимости как явные внешние (полезно для объявления последовательности зависимостей от производства, сервера непрерывной интеграции).

Теперь проект имеет 3 экземпляра кода, который агрегирует их атрибуты для окончательной сборки:

1. multiprojectRoot/проекта/SharedProjectBuildCode.scala: Содержит локальные зависимости и другой код, которые имеют значение для сборки нескольких проектов ,
2. multiprojectRoot/project1/project1-build.sbt: содержит атрибуты сборки проекта, общие для многопроектной и автономной сборки проекта, такие как имя или зависимости, которые всегда являются внешними. То же самое должно быть сделано для других многопроектных проектов того же уровня, которые должны быть явно рассмотрены как внешние артефакты зависимостей.
3. multiprojectRoot/project1/project/DeploymentOnlyCode.scala: Содержит атрибуты сборки, которые будут учитываться только для автономной сборки. То же самое можно сделать и для других подпроектов, если для этого требуется определить специфические атрибуты развертывания.

Это также дает максимальный контроль над тем, как строится проект, является ли выпуском артефакт или нет, и обрабатывать исходный код, релевантный только для данного проекта, в качестве полной и независимой части.

Answer 2

Я думаю, что вы должны иметь в 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) 

... 

И не нужно добавлять в зависимости в build.sbt больше.