GitHub - sbtsbt-Assembly Розгортання жирних JAR-файлів

Розгортайте жирні JAR. Перезапустіть процеси.

sbt-Assembly - це плагін sbt, спочатку перенесений з codahale's assembly-sbt, який, на мою думку, був натхненний плагіном збірки Maven. Мета проста: Створіть жирний JAR для вашого проекту з усіма його залежностями.

• sbt
• Пекуче бажання мати просту процедуру розгортання.

Повідомлення про проблеми та внесок

Перш ніж надіслати мені електронного листа, уважно прочитайте Правила звітності про проблеми. Двічі. (Не пишіть мені)

Використання опублікованого плагіна

Додайте sbt-Assembly як залежність у project/plugins.sbt:

(Можливо, вам доведеться перевірити теги цього проекту, щоб побачити останню версію.)

Оскільки sbt-Assembly тепер є автоматичним плагіном, який запускається для всіх проектів за допомогою JvmPlugin, він не повинен вимагати додаткових налаштувань для включення завдання складання у ваш проект. Детальніше про те, як здійснити оновлення зі старішої sbt-збірки, дивіться у посібнику з міграції.

Застосування плагіна до багатопроектного build.sbt

Наприклад, ось мультипроект build.sbt:

У наведеному вище прикладі як проект програми, так і проект utils не запускають тести під час складання. Проект програми встановлює основний клас, тоді як проект utils встановлює ім'я свого файлу jar.

Тепер у вас буде чудове нове завдання збірки, яке скомпілює ваш проект, запустить тести, а потім упакує файли класів та всі ваші залежності в один файл JAR: target/scala_X.X.X/projectname-Assembly-X.X.X.jar .

Якщо ви вказали mainClass у збірці в build.sbt (або просто дозволите йому самовизначення), то у вас вийде повністю виконуваний JAR, готовий до розгортання.

Ось список ключів, які можна перенаправити для завдання збірки.

Наприклад, ім'я банки можна встановити наступним чином у build.sbt:

Щоб пропустити тест під час складання,

Щоб встановити явний основний клас,

Виключення явного основного класу з вашої збірки вимагає чогось трохи іншого

Якщо декілька файлів мають один і той самий відносний шлях (наприклад, ресурс з іменем application.conf у декількох залежностях JAR), стратегія за замовчуванням полягає в тому, щоб перевірити, чи всі кандидати мають однаковий вміст, і в іншому випадку помилка. Цю поведінку можна налаштувати на основі кожного шляху, використовуючи одну з наступних вбудованих стратегій або написавши власну:

• MergeStrategy.deduplicate є типовим описаним вище
• MergeStrategy.first вибирає перший із відповідних файлів у порядку шляху до класу
• MergeStrategy.last вибирає останню
• MergeStrategy.singleOrError рятується повідомленням про помилку про конфлікт
• MergeStrategy.concat просто об’єднує всі відповідні файли та включає результат
• MergeStrategy.filterDistinctLines також об'єднується, але залишає дублікати в процесі
• MergeStrategy.rename перейменовує файли, що походять з файлів jar
• MergeStrategy.discard просто відкидає відповідні файли

Зіставлення імен шляхів для стратегій злиття здійснюється за допомогою параметра AssemblyMergeStrategy, який можна доповнити наступним чином:

ПРИМІТКА:

• AssemblyMergeStrategy в збірці очікує функції. Ви не можете виконати AssemblyMergeStrategy у збірці: = MergeStrategy.first !
• Деякі файли потрібно викинути або перейменувати в іншому випадку, щоб уникнути злому zip (через дублікат імені файлу) або юридичної ліцензії. Делегуйте обробку за замовчуванням до (AssemblyMergeStrategy у збірці) як наведений вище приклад відповідності шаблону.

До речі, перший шаблон у вищезазначеному випадку, використовуючи PathList (.) - це те, як ви можете вибрати javax/servlet/* з першої jar. Якщо за замовчуванням MergeStrategy.deduplicate не працює для вас, це, ймовірно, означає, що у вас є кілька версій якоїсь бібліотеки, витягнутої вашим графіком залежностей. Реальним рішенням є виправлення цього графіка залежності. Ви можете обійти це за допомогою MergeStrategy.first, але не дивуйтеся, коли побачите ClassNotFoundException .

Ось за замовчуванням:

Спеціальні MergeStrategy s можуть з’ясувати, звідки береться певний файл, використовуючи метод sourceOfFileForMerge на sbtassembly.AssemblyUtils, який приймає в якості параметрів тимчасовий каталог та один із файлів, переданих у стратегію.

Сторонні плагіни для злиття стратегій

Підтримку спеціальних стратегій злиття, що виходять за рамки загальної сфери застосування, можуть надати супутні плагіни, нижче наведено неповний список:

sbt-Assembly може відтіняти класи з ваших проектів або з бібліотечних залежностей. За підтримки Jar Jar Links перетворення байт-коду (через ASM) використовується для зміни посилань на перейменовані класи.

Ось правила тіні:

• ShadeRule.rename ("x. **" -> "y. @ 1",.) .InAll Це головне правило.
• ShadeRule.zap ("a.b.c"). InAll
• ShadeRule.keep ("x. **"). InAll

Основне правило ShadeRule.rename використовується для перейменування класів. Усі посилання на перейменовані класи також будуть оновлені. Якщо назва класу відповідає кільком правилам, застосовуватиметься лише перше. Правила перейменування приймають варіант пар рядків

- це назва класу з необов’язковими символами підстановки. ** збігатиметься з будь-яким дійсним підрядком імені класу. Для узгодження одного компонента пакета (виключенням. Із відповідності) замість нього може бути використаний один *. це ім'я класу, яке за бажанням може посилатися на підрядки, відповідні підстановчим символам. Нумерована посилання доступна для кожного * або ** в

, починаючи зліва направо: @ 1, @ 2 тощо. Спеціальне посилання @ 0 містить ціле відповідне ім'я класу.

---