sbt dependOn, typesafe config объединяет application.conf

У меня есть проект с двумя модулями, A и B. У каждого есть application.conf и local.conf, которые включают первый. В файле build.sbt моего проекта указано:

B.dependsOn(A % "compile->compile")

Похоже, что local.conf для модуля B включает application.conf для модуля A, потому что я получаю исключение UnresolvedSubstitution для замещенных значений в application.conf модуля A при попытке запустить модуль B.

Я думаю, что это слияние файлов application.conf. Есть ли способ остановить это? В частности, можно ли это сделать через файл build.sbt?


dependencies sbt typesafe-config
person Logician    schedule 24.10.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Когда вы делаете это:

B.dependsOn(A % "compile->compile")

что происходит, так это то, что когда B компилируется, он выполняет компиляцию A и делает ее доступной для B. Это означает, что ваши файлы конфигурации в A будут доступны для B, потому что конфигурация Type-Safe помещает эти конфигурации в путь к классам.

Самым простым решением, вероятно, является пространство имен ваших свойств, чтобы модуль B использовал свойства только из своей собственной конфигурации, а не As. (Это лучшая практика, позволяющая четко разделять задачи.) Если конфигурация B предназначена для переопределения конфигурации A по умолчанию и предполагается, что A по сути является библиотекой, используемой B, выполните следующие действия. рекомендации здесь и поместите файл resource.conf в A, а файл application.conf в B, так как application.conf имеет более высокий приоритет.

В вашем случае и A, и B полагаются на общий код. Чтобы сохранить разделение задач, лучше всего преобразовать этот общий код в отдельный библиотечный модуль и сделать так, чтобы оба A и B ссылались на этот код. Таким образом, вы можете гарантировать, что свойства, на которые они оба полагаются, находятся в C, а свойства, которые правильно установлены либо A, либо B, находятся только в их домене.

person Nathaniel Ford    schedule 25.10.2016
comment
К сожалению, на практике A и B являются приложениями, а не библиотеками, но у A есть clasd, который я хочу уже закодировать в B, поэтому я решил импортировать его, чтобы уменьшить дублирование кода и, следовательно, зависимость. Итак, что именно вы подразумеваете под пространством имен? Поможет ли это в данной ситуации? - person Logician; 25.10.2016
comment
Обычно, если есть два приложения, которые ссылаются на похожие классы, эти классы перемещаются в библиотечный модуль, который могут вызывать оба приложения. Пространство имен означает добавление префикса к вашему свойству, чтобы было ясно, где он находится. Например, пространство имен java.util.List равно java.util, поэтому его не следует путать с com.mystuff.shopping.List. В этом случае вы можете сделать A.someproperty и B.someproperty. - person Nathaniel Ford; 25.10.2016
comment
Спасибо, Натаниэль, я думаю, что решение с общей библиотекой оптимально, и я буду использовать его. Должен ли я отметить вышеуказанный пост как свое решение, или один из нас должен создать новый? - person Logician; 27.10.2016
comment
@Логик Готово! Извините, что так долго; был мобильным. - person Nathaniel Ford; 28.10.2016