Sbt multi-module build - поддерживать график модулей модулей как библиотеки зависимостей в модулях

Я пытаюсь придумать структуру для большого многомодульного проекта sbt, который удовлетворяет следующим требованиям:

  1. При построении корневого проекта зависимости в первую очередь разрешаются из модулей, доступных в корневом каталоге (т. Е. Если модуль A зависит от модуля B версии 2, которая является версией B, доступной в корневом каталоге, удовлетворяют требованиям зависимость от того, что производит сборка для B)

  2. Когда модули создаются индивидуально, зависимости разрешаются из репозиториев (локальных, кешированных, удаленных).

Мне известно о двух средствах определения зависимостей для проекта sbt: dependsOn () и ключ настройки libraryDependencies.

До сих пор в моей наивной структуре, где вся информация о сборке для модулей (A, B) отслеживалась в корне, я просто передавал .depends на ссылки проекта, и межмодульные зависимости были правильно разрешены в сборке R

текущая сборка

Что я хотел бы сделать, так это переместить / отследить эту взаимосвязь в файле build.sbt самих модулей, которые затем размещаются в отдельных репозиториях (и иногда возвращаются к «агрегатному» тегу репозитория родительского проекта через git подмодуль)

желаемая сборка

У меня никогда не было проблем с этим с maven (я предполагаю, что из-за возможности явно ссылаться на родительский элемент в модуле pom и есть только один способ установить зависимость), но я пока не могу понять, как чтобы начать в SBT

Итак, мой вопрос: придется ли мне писать для этого собственный преобразователь? Есть ли что-нибудь очевидное, что мне здесь не хватает?

Спасибо.


module scala sbt multi-module
person pgn    schedule 25.09.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

У меня также есть аналогичная установка с общим проектом с более чем 100 подпроектами. Подпроекты также находятся в собственном репозитории и могут быть созданы / опубликованы отдельно или как часть общего проекта. Мне не нужен специальный резолвер, чтобы это работало.

Я просто комбинирую оба описанных вами подхода:

проект А:

groupId := "groupId"
version := "1.0.0-SNAPSHOT"
libraryDependencies += "groupId" %% "B" % version

проект B:

groupId := "groupId"
version := "1.0.0-SNAPSHOT"

проект R:

lazy val a = (project in file(a)).dependsOn(b)
lazy val b = (project in file(b))

Я заметил, что sbt достаточно умен, чтобы не включать зависимость от b дважды.

person Frederic A.    schedule 26.09.2017
comment
Спасибо. Что произойдет, если версия b в родительском элементе не удовлетворяет требованиям к версии для библиотечных зависимостей в a? - person pgn; 26.09.2017
comment
@pgn Я не знаю, сейчас я управляю номерами версий централизованно, чтобы избежать этой проблемы. Я могу только догадываться, что sbt будет действовать как обычно в случае нескольких одинаковых зависимостей с разными версиями: выберите последнюю версию. - person Frederic A.; 26.09.2017
comment
Позвольте мне проверить это на небольшом проекте. Я надеюсь, что он попытается перейти в кеш / локальное / удаленное репо - person pgn; 26.09.2017