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

Question

Я разрабатываю несколько модулей с зависимостями между ними и хотел бы работать с ними вместе в одном проекте IDEA. Я использую sbt-idea для генерации проектов IDEA из определений сборки sbt, что прекрасно работает для отдельных проектов. Однако в случае с несколькими модулями вещи, которые я до сих пор пробовал, не совсем работают:

Используйте sbt-idea для создания файла IDEA .iml для каждого модуля независимо ; затем создайте основной проект IDEA с нуля и добавьте в него эти модули. Это делает исходные тексты модулей доступными для редактирования в одном и том же окне, но зависимости между ними не отслеживаются (поэтому попытка перейти от какого-либо источника в проекте foo к чему-то в bar приводит меня к импортированной версии библиотеки bar , а не к локальным источникам).

Использование sbt многопроектных сборок (он же подпроект) , где Build.scala родительского проекта содержит такие вещи, как:

lazy val foo = Project(id = "foo", base = file("foo"))
lazy val bar = Project(id = "bar", base = file("bar")) dependsOn(foo)

Это почти работает, так как sbt-idea генерирует основной проект IDEA с отслеживаемыми зависимостями среди подпроектов. Однако есть две оговорки:

1. Кажется, что ограничение sbt заключается в том, что подпроекты должны находиться в подкаталогах главного проекта (т. Е. file("../foo") не допускается). Это на самом деле не то, что я хочу (что, если модуль - такой как пакет "utils" или "commons" - используется в двух разных главных проектах?), Но я могу жить с этим.
2. Один из моих подпроектов имеет свои собственные подпроекты; Я не уверен, правильно ли работает sbt с этими вложенными проектами, но в любом случае они игнорируются sbt-idea. Очевидно, что мне нужно, чтобы вложенные подпроекты рекурсивно включались в главный проект.

Подводя итог: я хотел бы собрать модули , которые могут уже иметь подпроекты , в один большой проект IDEA с отслеживаемыми зависимостями для удобного редактирования. Как мне это сделать? Спасибо!

Answer 1

Кажется, что ограничение sbt заключается в том, что подпроекты должны находиться в подкаталогах главного проекта (т. Е. Файл ("../ foo") не разрешен).Это на самом деле не то, что я хочу (что, если модуль - такой как пакет "utils" или "commons" - используется в двух разных главных проектах?), Но я могу жить с этим.

С помощью sbt 13.5 и intellij 13.x вы можете указать межпроектную зависимость с относительным путем, используя Build.scala .Допустим, у вас есть два проекта: основной проект commons и другой проект foo , оба из которых живут в общем каталоге code /

1. создайте Build.scala под кодом / foo / project /

2. вставьте этот фрагмент кода в Insile Build.scala

   object ProjectDependencies {
       val commons = RootProject(file("../commons"))
   }
   
   object ProjectBuild extends Build {
       import ProjectDependencies._
   
       lazy val root = Project(id = "foo", base = file(".")).dependsOn(commons)
   }
   

3. Создайте проект IntelliJ через sbtsbt gen-idea

Answer 2

Подход с многопроектной сборкой является правильным.Вы можете иметь вложенное дерево подпроектов произвольной длины, но вы не можете иметь модуль, принадлежащий нескольким родительским проектам.Это имеет абсолютно смысл, и в Maven происходит то же самое.

Причина в том, что было бы трудно иметь один и тот же модуль в нескольких проектах и ​​поддерживать синхронизацию источников.Обычный рабочий процесс выглядит следующим образом:

• У вас есть проект, к которому принадлежит модуль, где вы модифицируете источник модуля.
• Вы публикуете модуль в своем локальном репозитории
• В других проектах, где вам нужен модуль, вы объявляете его как libraryDependency

Если вы хотите загрузить модуль, который не принадлежит текущему проекту внутри Idea, это возможно, так какВы можете добавить это как внешний модуль в рабочую область:

• SBT-IDEA генерирует файлы .iml для вашего проекта и импортирует их в рабочую область
• Вы можете добавить другие.из других проектов в рабочую область
• Если вы модифицируете внешние модули SBT, которые вы добавили в рабочую область вручную, вы должны повторно опубликовать их, чтобы увидеть изменения в «основном» проекте, который видит, что эти внешние модулиa "libraryDependency"