Номера версий для наших банок должны быть длиннее x.x.x. Нам скорее нужен x.x.x.x, чтобы интегрировать какой-нибудь старомодный самодельный механизм. Это связано с тем, что мы помечаем наше программное обеспечение с помощью x.x.x, и как только мы получаем доставку клиенту, одна конкретная банка должна быть собрана именно в этот момент времени, чтобы соответствовать другому бэкенду, который взаимодействует с нашей программой. По этой причине этот jar-файл имеет версию 2.3.4.1, при создании и в следующей поставке той же версии он создается и называется 2.3.4.2. Артефактори не может с этим справиться и в некоторых случаях не сохраняет больше x.x.x.2. Поэтому мы подумали о том, чтобы, возможно, отредактировать регулярное выражение в макете репозитория maven (см. Прикрепленный снимок экрана). Поскольку проверка пути в поле ниже показывает, что он не может обрабатывать номер версии. Конечно, для остальных наших банок все еще x.x.x должен работать..
Например, вот maven-metadata.xml
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>com.firm</groupId>
<artifactId>someid</artifactId>
<version>1.5.1</version>
<versioning>
<latest>1.5.1</latest>
<release>1.5.1</release>
<versions>
<version>1.4.62</version>
</versions>
<lastUpdated>20120926073942</lastUpdated>
</versioning>
</metadata>
Структура папок выглядит так:
Someid - 1.4.62 - 1.4.62.1 - 1.4.62.2 - 1.4.62.3
Если мы развернем новую версию артефакта (1.4.62.1), файл maven-metadata.xml будет содержать версию 1.4.62.1. Но артефактор переопределяет номер версии (1.4.62.x) на (1.4.62) через неопределенное время. Кажется, что артефакт поддерживает только основные, второстепенные номера и номера ревизий и удаляет номер сборки. Теперь мы ищем решение, отключите это поведение. Мы используем JFrog Artifactory версии 2.5.0 (версия 13086).
