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

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

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

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

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

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

В смысле? Перед релизом собираетесь редактировать еще и зависимости в pom.xml, а не только подправлять версию самого релиза?

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

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

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

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

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

$  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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

svn diff

Лови svnщика!

Да, блин. Консервативны они тут.

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