Выборочно включить зависимости в JAR

Question

У меня есть библиотека, которую я написал в Scala, которая использует Bouncy Castle и имеет целую кучу зависимостей.Когда я бросаю банку, я могу либо бросить «толстую» банку с всеми зависимостями (включая scala), которая весит около 19 МБ, либо я могу бросить тощую банку, которая неесть зависимости, но составляет всего несколько сотен килобайт.

Проблема в том, что мне нужно включить классы / банку Bouncy Castle в мою библиотеку, потому что, если она не находится на пути к классам во время выполнения, будут выдаваться все виды исключений.

Итак, я думаю, что идеальная ситуация, если есть какой-то способ, которым я могу заставить Maven или SBT включить некоторые , но не все зависимости в банке, которыекатится.Некоторые зависимости необходимы во время компиляции, но , а не во время выполнения, такие как стандартные библиотеки Scala.Есть ли способ добиться этого?

Спасибо!

Answer 1

Я бы попробовал подключаемый модуль sbt proguard из https://github.com/nuttycom/sbt-proguard-plugin. Он должен быть в состоянии отсеять классы, которые не используются.

Answer 2

Если достаточно явно указать, какие зависимости следует добавить (один на уровне артефакта, т. Е. Отдельные JAR-файлы), вы можете определить сборку (в случае одного проекта) или дополнительную сборочный проект (в случае многомодульного проекта). Дескрипторы сборки могут явно исключать / включать артефакты из зависимостей.

Здесь - хорошая документация по этой теме (раздел 8.5.4), здесь - официальная документация.

Обратите внимание, что вы можете включить все артефакты, принадлежащие к одной группе, используя символ подстановки в зависимости от набора, например, hibernate:*:jar будет включать все файлы JAR, принадлежащие к группе гибернации.

Answer 3

Я не скала, но я много занимался сборкой на Java + Maven.

Вы пытались создать собственный дескриптор сборки для плагина сборки? https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html

Вы можете скопировать / вставить дескриптор jar-with-dependencies, а затем просто добавить некоторые исключения в ваш . Я не эксперт по Maven, но вы сможете настроить его так, чтобы разные профили запускали разные сборки.

РЕДАКТИРОВАТЬ: Ack, не видел, что мой HTML скрыт

Answer 4

Покрытие мавен ...

Поскольку вы объявляете, что ваш проект зависит от надувного замка в вашем maven pom, любой, кто использует maven для зависимости от вашей библиотеки, по умолчанию использует надувной замок как транзитивную зависимость .

Вы должны установить соответствующую область действия в зависимости, например. скомпилируйте для вещей, необходимых во время компиляции и во время выполнения, протестируйте на зависимости, необходимые только для тестирования и предоставленные для вещей, которые вы ожидаете предоставить в среде.

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

Например, упаковка типа jar по умолчанию не включает зависимости, тогда как war будет включать в себя те, которые находятся в области компиляции (но не тестируются или не предоставляются). Цель проекта заключалась в том, чтобы упаковочные плагины работали наиболее часто, без необходимости в конфигурации, но, конечно, упаковочные плагины в Maven могут быть настроены на другое поведение при необходимости. Сами плагины, которые делают упаковку, хорошо документированы на сайте apache maven.

Если пользователи вашей библиотеки вряд ли будут использовать maven для создания своих проектов, можно использовать плагин shade, который позволит вам создать «uber-jar», который содержит все зависимости, которые вы хотите. Вы можете настроить отдельные включения или исключения.

Это может быть проблематичным способом доставки, например, когда ваша библиотека содержит зависимости, версия которых конфликтует с прямыми зависимостями проектов, использующих ее, то есть они используют другую версию той же библиотеки, что и ваша.

Однако, если вы можете, лучше оставить это для управления maven, чтобы проекты, использующие вашу библиотеку, могли решать, хотят ли они ваших зависимостей, или указывать конкретные версии, предоставляя им большую гибкость. Это идиоматический подход.

Для получения дополнительной информации о зависимостях и областях применения в maven см. Справочное руководство , опубликованное Sonatype.