Чтение файла свойств из файла POM в Maven

Почему это НЕ работает? Как выбрать номера версий из файла свойств.

Чтение свойств в pom.xml

<project>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
          </execution>
          <configuration>
            <files>
              <file>dev.properties</file>
            </files>
          </configuration>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

В dev.properties

org.aspectj.aspectjrt.version = 1.6.11

Зависимость в pom.xml

        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjrt</artifactId>
            <version>${org.aspectj.aspectjrt.version}</version>
        </dependency>

Ошибка: зависимость должна быть допустимой версией

Ответы

Ответ 1

Когда вы запускаете Maven из командной строки, он проходит через несколько этапов. Вот псевдоописание этих этапов, я намеренно упрощаю точное упорядочение (с риском сказать немного неправильные/не по порядку), чтобы вы могли понять, почему то, что вы пытаетесь сделать, не может работать.

  • Сначала он анализирует вашу командную строку, любые свойства, определенные в командной строке с помощью -Dname=value, вводятся в MavenSession

  • Параметры, определяющие параметры командной строки, проверяются, чтобы решить, какой должен быть список проектов для создания (также известный как реактор). -N означает, что только корневой каталог pom.xml, -pl позволяет указать список модулей для сборки, -am и -amd позволяет добавлять модули вверх или вниз по течению, соответственно, из тех, которые определены -pl. Maven не проанализировал файлы pom.xml в этот момент времени.

  • Правила активации профиля -P анализируются, чтобы узнать, какие профили активировать.

  • Теперь у Maven достаточно знаний, чтобы начать синтаксический анализ файлов pom.xml. Он начинается с загрузки и разбора корня pom.xml, то есть одного в текущем каталоге (или если вы указали альтернативный pom.xml с -f, а затем тот). Этот начальный синтаксис просто концентрируется на определении списка проектов для сборки. Активация профиля учитывается только в той мере, в какой это может повлиять на список доступных <modules>. Идентификаторы группы Id, Artifact Id, Version и Packaging в pom.xml не могут содержать свойства, поскольку синтаксический анализ свойств в pom.xml не состоялся в этот момент времени. (Наблюдательный читатель также увидит, что это также объясняет, почему вы не можете активировать профили на основе свойств в pom.xml, так как на этом этапе были проанализированы только системные свойства)

  • После того, как набор проектов был проверен, Maven теперь выполняет более синтаксический анализ этих pom.xml файлов для создания списка расширений сборки (если есть) и списка плагинов. На этом этапе синтаксический анализ требует оценки <properties> в каждом проекте, так что это когда они оцениваются и "вводятся" в эффективную модель. Таким образом, вы можете использовать свойства системы и свойства pom для определения координат и дополнительных зависимостей внутри (xpath) /project/build/extensions, /project/build/pluginManagement/plugins/plugin, /project/build/pluginManagement/plugins/plugin/dependencies, /project/build/plugins/plugin и /project/build/plugins/plugin/dependencies.

  • Теперь Maven начинает разбор списка целей и фаз, указанных в командной строке. Частично заданные цели оцениваются для соответствия списку плагинов. Матч должен быть уникальным для всех проектов, с которыми будет выполняться цель плагина (т.е. Если это цель агрегатора, совпадение требуется только в корне, но для всех других "нормальных" целей короткое имя плагина должно быть тот же плагин для всех проектов). Фазы жизненного цикла должны быть из одного из жизненных циклов по умолчанию или из жизненного цикла, определенного в расширении сборки.

  • Из проанализированного списка целей и этапов Maven строит план сборки, т.е. что он собирается делать, на каких проектах и ​​в каком порядке. Для этого Maven должен проанализировать список зависимостей проектов, определенных в файлах проектов pom.xml. Это связано с тем, что зависимость может создаваться другим проектом внутри реактора, тем самым вызывая последовательность выполнения проекта. Таким образом, вы можете использовать свойства системы и свойства pom для определения координат и дополнительных зависимостей внутри (xpath) /project/dependencyManagement/dependencies/dependency и /project/dependencies/dependency, но обратите внимание, что на данный момент плагины не были выполнены.

  • Теперь, когда Maven имеет план сборки, он начинает следовать этому плану в том порядке, в котором он был построен. Если первой целью/фазой в CLI была цель, то эта цель будет вызвана. Если первая цель/фаза была фазой от жизненного цикла сборки по умолчанию, то Maven начнет с фазы initialize и выполнит все плагины, привязанные к этой фазе... продолжая аналогичным образом по списку фаз, а затем список проектов. Также обратите внимание, что фаза initialize выполняется только как часть жизненного цикла сборки по умолчанию. Он не выполняется в стандартных жизненных циклах по умолчанию или по умолчанию, и он не выполняется ни на каких пользовательских жизненных циклах. (Наблюдательный читатель сделает вывод, что это указывает на еще одну проблему с техникой, которую пытается решить этот вопрос). Примечание: имейте в виду, что цели агрегатора образуют "перерыв" в реакторе, поэтому, если вы попросите Maven запустить clean package foo:bar site, где foo:bar является целью агрегатора mojo, тогда clean package будет выполняться со всеми проектами в реактор, то foo:bar будет работать против корня, тогда site будет работать против всех проектов в реакторе. Другими словами, план построения будет обеспечивать самый продолжительный непрерывный запуск целей и фаз не-агрегатора, разделенных на самые длительные непрерывные цепочки агрегаторов.

  • Прежде чем он вызовет каждое mojo (т.е. цель привязана к фазе или непосредственно указана в командной строке), Maven оценивает pom.xml для эффективного <configuration> этого mojo. На этом этапе Maven имеет доступ к свойствам системы, свойствам, указанным в pom, и любым свойствам, введенным в MavenSession ранее выполненными mojos. Таким образом, <configuration> может ссылаться на любое из этих свойств...

    Помимо

    Теперь есть оговорка... если вы скажете set (xpath) /project/build/directory на ${some-property-i-will-set-via-a-mojo}, а затем ссылаетесь на это из вашего <configuration>, ну, печальная новость заключается в том, что (xpath) /project/build/directory будет оценивается в эффективном pom.xml перед любым исполнением плагина, поэтому ${project.build.directory} будет выдано буквальное значение ${some-property-i-will-set-via-a-mojo} и имеет тип java.io.File в MavenProject, так что вы на самом деле имели место, это new File(project.getBaseDir(),"${some-property-i-will-set-via-a-mojo}"). Если поле <configuration>, которое вы вводите, имеет тип File, не потребуется никакого преобразования типа, и, следовательно, значение будет вводиться прямо, и никакая замена свойства не будет иметь места.

    Существуют и другие случаи кросс, как описано выше, но в целом замена свойств будет работать с свойствами "вложенных в mojo" (например, такими, которые предоставляются Mojo Свойства Maven Plugin) в разделах <configuration>. Он не будет работать за пределами этих разделов.

Итак, это быстрое правило Stephen для разных типов свойств:

Свойства системы

Они работают повсюду... но чрезвычайно опасны в /project/(parent/)?/(groupId|artifactId|version|packaging), так как вы не можете контролировать, что когда-либо будет определено, какие свойства системы будут определены при втягивании проекта в качестве транзитивной зависимости. Использование расширения ${...} в пределах /project/(parent/)?/(groupId|artifactId|version|packaging) должно рассматриваться как эквивалентное вождению автомобиля при 200 км/ч с металлическим шипом на 30 см (12 дюймов), выступающим с рулевого колеса вместо подушки безопасности... ох и без ремня безопасности.. и у вас только что было 10 единиц алкоголя и две линии кокаина.

pom.xml свойства (и settings.xml свойства)

Они работают в большинстве мест, но никогда не доступны в /project/(parent/)?/(groupId|artifactId|version|packaging) (поскольку они не были проанализированы, когда эти поля оцениваются) и недоступны для рассмотрения активных профилей (опять же, поскольку они не были проанализированы, когда проверка профиля)

Введенные свойства Mojo

Они работают в разделах <configuration> и могут (из-за рекурсивной интерполяции введенных параметров Mojo String) работать при косвенном использовании, но с учетом неопределенности рекомендуется ограничить их использование секцией <configuration> только для плагинов и отчетов.

Последняя вещь

Подумайте, что произойдет, когда ваш проект указан как зависимость. Если вы указали свои зависимости, используя mojo, чтобы вытащить файлы из файла .properties на диск, Maven не имеет возможности реплицировать это, когда ваша зависимость была вытащена из репозитория Maven. Таким образом, Maven не сможет определить зависимости. Таким образом, он никогда не сможет работать.

Что вы можете сделать, это использовать внешнюю систему (например, ANT) для генерации pom.xml из шаблона с замененными версиями в этот файл. А затем используйте созданный экземпляр шаблона.

Ответ 2

Этот файл properties(dev.properties) для задания сборки.

<files>
   <file>dev.properties</file>
</files>

Для зависимостей вам нужно добавить, как показано ниже в файле pom.xml.

<properties>

<org.aspectj.aspectjrt.version>1.6.11</org.aspectj.aspectjrt.version>
</properties>