Что такое расширение для конфигурации?

Ответ 1

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ У меня есть довольно базовое понимание концепции config sbt.

tl; dr Расширение конфигурации заключается только в том, чтобы наследовать группы зависимостей, а не настройки.

Из источников окончательный класс класса конфигурации:

def extend(configs: Configuration*) = Configuration(name, description, isPublic, configs.toList ::: extendsConfigs, transitive)

По умолчанию extendsConfigs есть Nil, как можно видеть в объекте sbt.Configurations:

def config(name: String) = new Configuration(name)

который разрешает (note Nil)

def this(name: String) = this(name, "", true, Nil, true)

В sbt.IvySbt.toIvyConfiguration:

import org.apache.ivy.core.module.descriptor.{ Configuration => IvyConfig }

и что там, где поддержка концепции config заканчивается в sbt и Ivy, выполните шаги, которые вам нужно будет посмотреть на документацию Ivy.

Но перед этим прочитайте Пример дополнительных конфигураций, в котором говорится:

Это пример определения .scala build, который демонстрирует использование Ivy конфигурации для группировки зависимостей.

Это начало объяснения. Конфигурации Ivy - группировать зависимости, а extend конфигурация - это расширение группировки.

Из официальная документация Айви об элементе conf:

конфигурация - это способ использования или построения модуля. (...) модулю могут потребоваться некоторые другие модули и артефакты только во время сборки, а некоторые другие - во время выполнения. Все эти разные способы использования или сборки модуля вызываются в конфигурациях модулей Ivy.

Считая, что вы можете найти ответ на свой вопрос (что я сам еще не перевариваю):

Конфигурация также может распространять один или несколько других из них модуль. Когда конфигурация расширяет другую, то все артефакты требуемые в расширенной конфигурации, также потребуются в которая расширяет другую. Например, если конфигурация B расширяет конфигурацию A, и если артефакты art1 и art2 требуются в конфигурации A, то они будут автоматически необходимых в конфигурации B. С другой стороны, артефакты, требуемые в конфигурация B необязательно требуется в конфигурации A.

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

В нижней части страницы есть раздел "Примеры" с примером с конфигурацией runtime, в котором "среда выполнения" будет состоять из всех зависимостей, все транзитно, включая зависимости, объявленные только в компиляции ".

С этим теперь вы можете понять концепцию config в sbt как группы зависимостей и что сгруппировано в Compile доступно в runtime как его определение выглядит следующим образом:

lazy val Runtime = config("runtime") extend (Compile)

Ответ 2

Мне просто нужно было понять это, поэтому я подумал, что это стоит того, чтобы разъяснить. Конфигурация должна быть добавлена ​​в проект для делегирования в расширенную конфигурацию:

lazy val KateBush: Configuration = config("katebush") extend Compile

lazy val root = (project in file(".")).configs(KateBush)

будет работать нормально. Если вы

inspect katebush:compile

то вы можете просмотреть цепочку делегирования:

...
[info] Delegates:
[info]  katebush:compile
[info]  compile:compile
[info]  *:compile
[info]  {.}/katebush:compile
[info]  {.}/compile:compile
[info]  {.}/*:compile
[info]  */katebush:compile
[info]  */compile:compile
[info]  */*:compile
...