Maven: Pom-файл — перенос версий зависимостей в файл свойств

#maven

#maven

Вопрос:

Я хотел бы экстернализировать версии зависимостей в файле POM в файл свойств.

Пример: pom.xml

 <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>${externalized.junit.version}</version>
</dependency>
  

abc.properties

 externalized.junit.version=4.8.2
  

Можно ли это сделать? Если да, то каков наилучший способ сделать это?

Комментарии:

1. Почему? Каков вариант использования?

2. Нет, вы не можете этого сделать. Какую проблему вы пытаетесь решить? Вы могли бы указать его как системное свойство, но это не очень хороший способ получить воспроизводимую сборку.

3. Имеет ли это смысл?

4. нет, вы не можете. вариантом может быть создание файла «спецификации» и использование механизма импорта для распространения одних и тех же версий: maven.apache.org/guides/introduction /…

Ответ №1:

Нет, вы не можете этого сделать.

Когда вы запускаете команду Maven в проекте, первое действие, которое она выполняет, — это создание эффективной модели проекта. В частности, это означает чтение вашего файла POM, сопоставление с активированными профилями, применение наследования, выполнение интерполяции свойств… все это для построения окончательной модели Maven. Эта работа выполняется компонентом Maven Model Builder, точкой входа которого является ModelBuilder интерфейс, а точкой выхода — Model класс.

Процесс построения модели довольно сложный, с большим количеством шагов, разделенных, возможно, на 2 фазы, но суть проблемы здесь проста: в конце этого шага существует действительная эффективная модель, которая будет использоваться Maven. Это означает, что все зависимости должны иметь действительные идентификаторы групп, идентификаторы артефактов, версии; что нет повторяющихся зависимостей, нет выполнения плагина с одинаковыми идентификаторами и т.д. (обратитесь к описанию модели).

Обратите внимание, что во время построения модели происходит интерполяция, что означает, что если свойство доступно в то время, и оно использовалось, например ${myProperty} , то оно будет заменено соответствующим значением. Среди доступных свойств:

  • Содержимое POM, например ${project.version} или ${project.artifactId} ;
  • ${project.basedir} , который соответствует каталогу, в котором pom.xml находится;
  • пользовательские свойства, установленные в командной строке с помощью -D переключателя (например -DmyProperty=myValue );
  • любые свойства, установленные непосредственно в файле POM, внутри <properties> элемента;
  • несколько встроенных свойств Maven, таких как ${maven.build.timestamp} , которые представляют дату / время начала сборки или ${maven.version} для текущей версии Maven;
  • Системные свойства Java, возвращаемые System.getProperties()
  • переменные среды;
  • и, наконец, свойства, установленные внутри settings.xml файла.

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

Это именно то, что здесь не работает: вы хотели бы, чтобы Maven мог читать версии внутри файла свойств, поэтому это означает привязку плагина к определенной фазе жизненного цикла для чтения этого файла и каким-то образом ссылаться на свойства, прочитанные с использованием стандартных свойств Maven. Проблема в том, что все это будет происходить после того, как модель уже собрана, так что для этого слишком поздно. Весь этот процесс происходит до того, как даже начался жизненный цикл сборки; до этого нет возможности вызвать плагин.

Это также подразумевает, что это сработало бы, если бы вы определили свойство как свойство командной строки (поскольку, как указано выше, оно доступно во время процесса интерполяции при построении модели). Но это не лучшая практика: указание версии зависимости в качестве свойства командной строки затрудняет воспроизведение сборки. Лучше указать это как свойство Maven внутри <properties> элемента POM или использовать <dependencyManagement> схему в родительском POM или также импортировать спецификацию.

Ответ №2:

Если вам действительно нужно что-то подобное, самым простым способом было бы написать сценарий оболочки (или какую-либо другую короткую программу командной строки), которая копирует pom, заменяет указанные свойства в pom и вызывает maven.

Но, как было сказано ранее: вероятно, есть более похожие на Maven способы достичь того, чего вы хотите достичь.

Комментарии:

1. Нет, в некоторых вещах maven просто чертовски отстой 🙂