«Опакечивание» Java-проекта под Debian

Есть мнение что опакетить яву под дебиан не могут сами мэйнтейнеры, как пример jabref.

Как дебиановские

Если уж разговор зашёл за Debian и со стандартными тулзами траблы, то я могу посоветовать: https://github.com/BASH-Auto-Tools/bash-deb-build

С ним только одна проблема: ты должен знать внутреннее устройство своего пакета. Но эта проблема решаема: берётся уже готовый похожий пакет, распаковывается и делается свой «по-образцу».

PS: bash-deb-build не поддерживает xz.

Вози с собой тележку с jre и распаковывай все в /opt :)

Это похоже на шутку, но это не шутка.

Есть задача «опакетить» Java-проект под Debian.

рекомендация такого не делать.

Если это приложение, то его всегда его можно свести к java -jar , если сервис веб/невеб, то всегда можно свести к war .

Кроссплатформено и относительно удобно.

Никакие дебиановские рекомендации относительно Java выполнять не стоит. Я уверен, что никто из составлявших эти рекомендации не был Java-разработчиком

Нужно положить OpenJDK внутрь приложения и запаковать ровно в одно место на файловой системе. Но это опционально.

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

Всегда делаю это просто и стандартно. ХЗ, может это и вручную все расталкивать получается, но с dh-скриптами играться может получиться многократно сложней. Получается примерно так. Это если собирается в один супер-жар.

/usr/share/foo/foo.jar
/lib/systemd/system/foo.service
/var/log/foo

/usr/share/foo/foo.jar
/lib/systemd/system/foo.service
/usr/lib/foo/dep1.jar
/usr/lib/foo/dep2.jar
/var/log/foo

%:
        dh $@

override_dh_auto_build:
        mvn -Dmaven.test.skip=true -U clean package

override_dh_auto_clean:
        dh_auto_clean
        find -maxdepth 2 -type d -name target -exec rm -r {} \;

ExecStart=/usr/bin/java -server -Xms100500m -Xmx100500m \
                        -jar /usr/share/foo/foo.jar

тебе уже в целом всё написали.

Собери всё в /opt/myapp, чутка в /lib/systemd и это всё закатай с помощью dpkg-deb

Получишь рабочий пакет, которым можно пользоваться.

А как делается обновление приложения? Костылится менеджер обновлений?

Поэтому жаба-приложения не нужны, они нарушают строгую архитектуру дебиана

1. Никак не делается менеджер обновлений. Раз в N времени делается HTTP GET запрос на сервер приложения, он вытаскивает «текущую» версию. Если текущая и установленная отличаются - выдается диалоговое окно «бацька, бегите освежитесь срочно!». Отец идёт на сайт, качает и устанавливает новую версию двойным щелчком. Кстати, это самый безопасный способ для критически важных приложений.

2. Велосипедятся обновления. Так же - раз в N времени получаем версию, потом несколькими GET запросами вытягиваем джарки. Просим перезапустить приложение, в момент перезапуска подменяем старые джарки на новые. Всё, обновление сделано. Всё это можно написать за час.

Вопрос в том, что дальше у тебя будет куча проблем, которые придется отлаживать годами - например, у человека стоит какой-то HTTP прокси, через который не умеет ходить твой даунлоадер. Или ты его научил ходить через HTTP и SOCKS, но прокси теперь фильтрует все джарники, что начинаются на букву «а» (неизвестно почему, но теперь это твоя проблема). Причем, с репозиториями ОС всё эти проблемы могут никуда не исчезнуть!

3. Есть уже готовые фреймворки для обновлений, например, update4j

typical deb user :)

Если несколько то просто дополнительно зависимости ложил в /usr/lib/foo

это очень частный случай. Например, если у тебя приложение - это Electron, внутри которого запускается Tomcat и отдаёт интерфейс жабой, то так сделать не получится - нужна определенная структура директорий и джарки в ней лежат в определенных местах

Ясно, что можно наворорить лапши на JavaScript^WElectron^чем угодну, что потом нужно 10 человеколет чтобы это просто запустить. Такое просто делать не нужно изначально.

Нафига там вообще электрон? И неужели в мавене до сих пор нет встраиваемого электрона, который можно в fat jar втаращить?

А что насчет jpackage?

Есть уже готовые фреймворки для обновлений, например, update4j

Классно.

Чисто технически есть еще maven плагин для создание пакета: https://github.com/io-solit/deb-maven-plugin. По идее это лучше ляжет в случае автоматической сборки тем же дженкинсом или типа того.