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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не специалист по Scala, но я игрался с сборкой вещей в Java + Maven.

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

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

EDIT: Ack, не видел, чтобы мой HTML был скрыт