История изменений

Смотря кому.

Если ты про ТС... Ну я так понял, ТС именно это и хочет сделать. Это ж Gentoo, там принято всё из исходников.

А я его отговариваю и предлагаю сделать пакет из бинарей, которые уже собрали разработчики и выложили на своём сайте.

Если же ты про разработчиков дистрибутива, я предлагаю им перестать бредить идеей брать dependencies из pom.xml и пытаться превратить их в отдельные какие-нибудь deb-пакеты, чтобы потом связывать их через CLASSPATH. Эта идея кажется хорошей только до тех пор, пока не поймёшь, что разработчики софта про неё ничего не знают, и например, какой-нибудь log4j-1.2.3.jar в двух разных программах может быть собран категорически несовместимым образом. Или что например, spring-1.2.3.jar зачастую нельзя проапгрейдить на spring-1.2.4.jar без того чтобы приложение перестало запускаться. Это какой-то очень долго доказываемый факт, но по результатам доооолгой практики для меня это вполне себе факт, подтвержденный статистикой: опакечивать Java-зависимости нельзя. Java-приложение - это «всё своё тащу с собой». Если бы я делал какой-то серьёзный продукт, я бы даже собственный билд OpenJDK засунул прямо внутрь дистрибутива программы от греха подальше.

Плюс, скорей всего, после отработки результата mvn package, софтина работать не начнёт :) Нужно будет писать ещё килотонну скриптов вручную, чтобы её правильно запустить. Это некое тайное знание, которое нужно экстрагировать чтением сайта соответствующей софтины и регулярным слежением за изменением руководств по установке. Чего мантейнеры дистрибутива, конечно делать не станут. Там в дистрибутивах всякие олдскульные линуксоеды, которые чисто верят, что после make install всё работает само собой - и нет, не работает. После осознания, что ничего не работает, они начинают метаться и писать чудовищные костыли и патчи, в надежде не разбираясь в вопросе и не читая документацию хоть как-то хоть что-то запинать чтобы заработало. Драматическое зрелище.

Смотря кому.

Если ты про ТС... Ну я так понял, ТС именно это и хочет сделать. Это ж Gentoo, там принято всё из исходников.

А я его отговариваю и предлагаю сделать пакет из бинарей, которые уже собрали разработчики и выложили на своём сайте.

Если же ты про разработчиков дистрибутива, я предлагаю им перестать бредить идеей брать dependencies из pom.xml и пытаться превратить их в отдельные какие-нибудь deb-пакеты, чтобы потом связывать их через CLASSPATH. Эта идея кажется хорошей только до тех пор, пока не поймёшь, что разработчики софта про неё ничего не знают, и например, какой-нибудь log4j-1.2.3.jar в двух разных программах может быть собран категорически несовместимым образом. Или что например, spring-1.2.3.jar зачастую нельзя проапгрейдить на spring-1.2.4.jar без того чтобы приложение перестало запускаться. Это какой-то очень долго доказываемый факт, но по результатам доооолгой практики для меня это вполне себе факт, подтвержденный статистикой: опакечивать Java-зависимости нельзя. Java-приложение - это «всё своё тащу с собой».

Плюс, скорей всего, после отработки результата mvn package, софтина работать не начнёт :) Нужно будет писать ещё килотонну скриптов вручную, чтобы её правильно запустить. Это некое тайное знание, которое нужно экстрагировать чтением сайта соответствующей софтины и регулярным слежением за изменением руководств по установке. Чего мантейнеры дистрибутива, конечно делать не станут. Там в дистрибутивах всякие олдскульные линуксоеды, которые чисто верят, что после make install всё работает само собой - и нет, не работает. После осознания, что ничего не работает, они начинают метаться и писать чудовищные костыли и патчи, в надежде не разбираясь в вопросе и не читая документацию хоть как-то хоть что-то запинать чтобы заработало. Драматическое зрелище.

Смотря кому.

Если ты про ТС... Ну я так понял, ТС именно это и хочет сделать. Это ж Gentoo, там принято всё из исходников.

А я его отговариваю и предлагаю сделать пакет из бинарей, которые уже собрали разработчики и выложили на своём сайте.

Если же ты про разработчиков дистрибутива, я предлагаю им перестать бредить идеей брать dependencies из pom.xml и пытаться превратить их в отдельные какие-нибудь deb-пакеты, чтобы потом связывать их через CLASSPATH. Эта идея кажется хорошей только до тех пор, пока не поймёшь, что разработчики софта про неё ничего не знают, и например, какой-нибудь log4j-1.2.3.jar в двух разных программах может быть собран категорически несовместимым образом. Или что например, spring-1.2.3.jar зачастую нельзя проапгрейдить на spring-1.2.4.jar без того чтобы приложение перестало запускаться. Это какой-то очень долго доказываемый факт, но по результатам доооолгой практики для меня это вполне себе факт, подтвержденный статистикой: опакечивать Java-зависимости нельзя. Java-приложение - это «всё своё тащу с собой».

Плюс, скорей всего, после отработки результата mvn package, софтина работать не начнёт :) Нужно будет писать ещё килотонну скриптов вручную, чтобы её правильно запустить. Это некое тайное знание, которое нужно экстрагировать чтением сайта соответствующей софтины и регулярным слежением за изменением руководств по установке. Чего мантейнеры дистрибутива, конечно делать не станут.