Как я уже сказал в комментариях, я бы выбрал другой маршрут. Если вы используете зависимости как управляемых зависимостей, вы можете затенять их как в самой библиотеке, так и внутри вашего проекта.
Давайте посмотрим пример:
Предположим, что у меня есть проект, который принимает зависимость от com.typesafe.config
. Я могу затенять его внутри собственной библиотеки, то есть внутри кода com.typesafe.config
, а также в библиотеке потребления.
Вы определяете это следующим образом:
assemblyShadeRules in assembly ++= Seq(
ShadeRule.rename("com.typesafe.config.**" -> "[email protected]")
.inLibrary("com.typesafe" % "config" % "1.3.0")
.inProject
)
Который в основном означает «взять что-нибудь, что существа с com.typesafe.config
и тени его к my_conf
.»
Обратите внимание, что мы используем как inLibrary
, так и inProject
. Первый означает «изменить имена пакетов внутри com.typesafe.config
» и inProject
означает «изменить все ссылки на com.typesafe.config
внутри моего кода».
Теперь вывод, что выглядит следующим образом:
Это как пакет внутри выглядит сейчас (my_conf
был первоначально com.typesafe.config
перед тем затенение):
И это пакет ваш код будет ссылаться:
Почему лет u используя отдельную сборку для затенения внешних зависимостей? Почему бы не взять их в качестве управляемых зависимостей и не затенять их внутри корня 'Build.scala'? –
, потому что мне нужно зависеть от классов после затенения. «Управляемые зависимости» будут вводить классы перед затенением. – manuzhang
Не обязательно. Если вы затеняете проект как 'inLibrary', так и' inProject', он также сбросит * внутренние зависимости *. –