LINUX.ORG.RU

Воспроизводимые сборки с maven

 ,


0

2

Кто как делает сабж в больших проектах? Имеется огромная система, которая содержит сотни модулей разработанных клиентом, которые в свою очередь используют другие сотни библиотек 3rd party.

Для того чтобы при разработке не было полного хаоса, для 3rd party на глобальном уровне выставляются интервалы версий вида [X.y;X+1.0), чтобы использовались всегда самые новые минорные версии, которые не ломают совместимость.

Вопрос, как обеспечить воспроизводимые на уровне версий модулей и библиотек 3rd party сборки релизов?

Теоретически это должно решаться с помощью mvn versions:resolve-ranges, но для наследованных версий этот метод не работает. Баг https://github.com/mojohaus/versions-maven-plugin/issues/298 открыт ещё в 2018м, но на него нет никакой реакции. Видимо, люди делают воспроизводимые сборки по-другому.

Кто как?

★★★★★

интервалы версий вида [X.y;X+1.0) и воспроизводимые сборки - это взаимоисключающие вещи, не находите?

увы, аналога простого механизма создания воспроизводимых сборок из мира rust я не знаю в мире java

dave ★★★★★ ()
Ответ на: комментарий от dave

интервалы версий вида [X.y;X+1.0) и воспроизводимые сборки - это взаимоисключающие вещи, не находите?

Не нахожу: [X.y;X+1.0) это в разработке, при релизе приводится к виду [a.b.c]. Вопрос только каким образом это сделать. Должен быть какой-то готовый велосипед.

alt-x ★★★★★ ()
Ответ на: комментарий от Legioner

Я просто указываю версии и всё. В чем суть проблемы не понимаю.

При явном указании версий этой проблемы нет, но есть другая: надо следить за всеми 3rd party, чтобы не пропусить исправления безопасности в commons-whatever-2.7.134 и не остаться с дырявой commons-whatever-2.7.133.

Чтобы проект всегда собирался делаю копию кеша в ~/.m2 и сохраняю его вместе с проектом. Проект должен собираться без инета.

Это да. Но он и соберётся при наличии интрАнета и нексуса. Иначе нужно ещё изобретать управления хранилищами .m2 от разных релизов.

alt-x ★★★★★ ()
Ответ на: комментарий от dave

Только версию.

$  mvn versions:resolve-ranges
...
$ svn diff
--- pom.xml     (revision 1160)
+++ pom.xml     (working copy)
@@ -15,12 +15,12 @@
         <dependency>
             <groupId>cool.and.fast.db</groupId>
             <artifactId>jdbc-connector</artifactId>
-            <version>[1.0,)</version>
+            <version>1.4</version>
         </dependency>
alt-x ★★★★★ ()
Ответ на: комментарий от alt-x

Нугуглил вот такую штуку: https://maven.apache.org/guides/mini/guide-reproducible-builds.html

Там говорят: «require to have no version ranges in dependencies»

Мне кажется, что вы на проекте просто заколебетесь менять версии в зависимостях. Да и это очень error-prone на мой частный взгляд делать такое в последний момент, потому что ваш код мог быть протестирован совсем с другими версиями библиотек, а вы тут, бац, и поменяли какую-то версию, не зная как она себя поведет в бою. Или вы собираетесь прямо из IDEA переносить руками номера версий... Не верю я в такое.

Может быть, что-то другое кроме maven умеет такое? Мне тоже интересно

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1)

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

cocucka ★★★★ ()
Ответ на: комментарий от dave

ваш код мог быть протестирован совсем с другими версиями библиотек, а вы тут, бац, и поменяли какую-то версию, не зная как она себя поведет в бою

Тестировщикам отдаётся релиз. В релизе версии зафиксированы. Ну, тут они так считали. А оказалось, что не совсем.

alt-x ★★★★★ ()
Ответ на: комментарий от cocucka

храним успешные релизы в репозитории

Тут их тоже хранят. Но вопрос больше про ветки: в релизе 10.2 обнаружился баг и надо его исправить и задеплоить не прихватив ничего лишнего.

alt-x ★★★★★ ()
Ответ на: комментарий от alt-x

Ну тогда и зависимости храните. У нас зеркало мавен-централа было ещё. Не всё, конечно, а только то, что хоть раз с централа было подтянуто. А то будет, как у фронтенд-макак, когда чувак либу удалил, которую все использовали.

cocucka ★★★★ ()
Ответ на: комментарий от alt-x

Я пользую versions:check-dependency-updates если правильно помню. Перед тем как тестировать релиз. Хотя все эти уязвимости в библиотеках это имхо надуманные проблемы. Уязвимость будет в самом приложении, в ОС, сервисах скорее.

Legioner ★★★★★ ()
Ответ на: комментарий от cocucka

Ну тогда и зависимости храните.

Так их и хранят. Вопрос только в том, как отследить моменты, когда mvn versions:resolve-ranges не резолвит и в релизе остаётся интервал.

alt-x ★★★★★ ()

Мы на sbt используем lock plugin, который фиксирует все версии в специальный файл lock.sbt. Его автоматически обновляем job’ой на jenkins, которая коммит новый lock-файл при его изменении (и еще умеет прикреплять changelog в commit message для наших компонентов).

Думаю на maven можно что-то аналогичное изобразить.

maxcom ★★★★★ ()

Просто не используйте мавен в 2020 году, там 1.5 разработчика осталось, которые делают что-то в свободное от работы время. Используйте gradle и либо его встроенный dependency-lock (не в курсе, вышел ли он из беты) либо nebula плагин

maloi ★★★★★ ()

Все версии выносятся в проперти в корневом pom. Все версии конкретные, без интервалов. За использование версии не через проперти в дочернем pom - клавиатурой по башке. На добавление новых библиотек - бюрократичекую процедуру с выбором версии и добавлением ее в корневой pom. Для сборки на CI - зеркало мавен (копия .m2 после одной сборки начисто) и ограничение только на него (чтобы CI сразу ломался).

В таком случае все воспроизводимо, а обновление версии для commons-wtf явно организовано как «небесплатное», так как оно по сути никак не может быть бесплатным, если не тащить в проект все подряд не глядя.

anonymous ()
Ответ на: комментарий от anonymous

Все версии выносятся в проперти в корневом pom. Все версии конкретные, без интервалов. За использование версии не через проперти в дочернем pom - клавиатурой по башке.

Т.е. при каждом билде вспомогательного компонента его надо релизить и обновлять корневой pom?

alt-x ★★★★★ ()
Ответ на: комментарий от alt-x

Вариант 1: вспомогательный компонент это модуль основного проекта, в таком случае он «не библиотека» и его версия всегда синхронизирована с версией самого проекта

Вариант 2: вспомогательный компонент используется в нескольких проектах, собирается отдельно от них и вообще живет своей жизнью. В таком случае это Библиотека и ее обновление - это Событие, для реализации которого существует бюрократическая процедура по обновлению корневого пома.

anonymous ()

Никогда не пытался, но задача интересная, я так понял очевидно нужно в классы реализующие интерфейс Serializable обязательно прописать явно поле static final long serialVersionUID иначе оно будет каждый раз генерироваться со случайным значением при компиляции.

anonymous ()