#dependencies #sbt #typesafe-config
#зависимости #sbt #typesafe-config
Вопрос:
У меня есть проект с двумя модулями, A и B . Каждый из них имеет application.conf и a local.conf , которые включают первый. build.sbt Файл моего проекта определяет:
B.dependsOn(A % "compile->compile")
Похоже, что local.conf for module B включает в себя application.conf for module A , потому что я получаю UnresolvedSubstitution исключение для подстановленных значений в A application.conf модуле B при попытке запустить module в.
Я думаю, что это слияние application.conf файлов. Есть ли какой-либо способ остановить это? В частности, могу ли я сделать это через build.sbt файл?
Ответ №1:
Когда вы делаете это:
B.dependsOn(A % "compile->compile")
происходит то, что при B компиляции выполняется A компиляция и становится доступной для B . Это означает, что ваши файлы конфигурации в A будут доступны для B , потому что типобезопасная конфигурация помещает эти конфигурации в classpath.
Вероятно, самым простым решением является создание пространства имен ваших свойств, чтобы модуль B использовал только свойства из своей собственной конфигурации и никогда A не использовал s. (Это лучшая практика, позволяющая четко разделять проблемы.) Если предполагается, что B конфигурация должна A переопределять A конфигурацию по умолчанию, и предполагается, что B по сути, это используемая библиотека, следуйте приведенным здесь рекомендациям по наилучшей практике и поместите resource.conf файл в A и application.conf файл в B , поскольку application.conf это имеет более высокий приоритет.
В вашем случае оба, A и B , полагаются на общий код. Чтобы сохранить разделение задач, лучше всего реорганизовать этот общий код в его собственный библиотечный модуль и иметь оба A и B ссылаться на этот код. Таким образом, вы можете гарантировать, что свойства, на которые они оба полагаются, находятся в C , а свойства, которые правильно установлены либо A , либо B находятся только в их домене.
Комментарии:
1. К сожалению, на практике оба A и B являются приложениями, а не библиотеками, но так получилось, что у A есть класс, который я хочу, чтобы в B уже был закодирован, поэтому я подумал, что импортирую его, чтобы уменьшить дублирование кода и, следовательно, зависимость. Итак, что именно вы подразумеваете под пространством имен? Поможет ли это в этой ситуации?
2. Обычно, если есть два приложения, которые ссылаются на похожие классы, для перемещения этих классов в библиотечный модуль, который могут вызывать оба приложения. Пространство имен относится к добавлению префикса к вашему свойству, чтобы было ясно, где оно находится. Например, пространство имен
java.util.Listявляетсяjava.util, чтобы его не путали сcom.mystuff.shopping.List. В этом случае вы можете сделатьA.somepropertyиB.someproperty.3. Спасибо, Натаниэль, я думаю, что решение common library является оптимальным, и я буду использовать это. Должен ли я пометить вышеприведенный пост как свое решение или кто-то из нас должен создать новый?
4. @Logician готово! Извините, что так долго; был мобильным.