Статьи

Знай своих плагинов MVN: сохранить здравомыслие в аду версии с открытым исходным кодом

Проблема № 1: Все знают, что идти в ногу с версиями сложно. По этой причине появляются такие инструменты, как OpenLogic . Некоторые компании платят, некоторые разрабатывают собственные решения, некоторые живут с версией, которая с каждым днем ​​стареет.

Проблема № 2: Когда несколько проектов с открытым исходным кодом, использованные вашим продуктом, могут принести разные версии одной и той же библиотеки. Никто никогда не знает, что будет обнаружено во время выполнения, и поведение на панели разработчика, основанное на законе Мерфи, будет отличаться от времени выполнения сервера.

Это не должно быть таким тяжелым испытанием. С помощью плагинов Maven это можно решить относительно легко. Версии Maven Plugin и Maven Enforcer Plugin на помощь!

Версии Плагин Maven будет поддерживать версии в актуальном состоянии, и, как вы, вероятно, догадались из названия, плагин Maven Enforcer будет защищать от нескольких версий артефакта maven в созданном пакете сборки.

Давайте посмотрим, как кто-то первым ввели миксер в микс. Код ниже может идти в родительском pom.xml проекта или глобальном родительском проекте, если таковой существует.

<project …>
<plugins>
<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>1.4</version>
        <executions>
          <execution>
            <id>enforce-versions</id>
            <goals>
              <goal>enforce</goal>
            </goals>
            <configuration>
              <rules>
                <requireMavenVersion>
                  <version>[2.2.*,)</version>
                </requireMavenVersion>
                <requireJavaVersion>
                  <version>[1.7.*,)</version>
                </requireJavaVersion>
                <DependencyConvergence/>
              </rules>
            </configuration>
          </execution>
        </executions>
      </plugin>
</plugins>
</project>

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

<project …>
<dependencies>
<dependency>
<groupId>com.lordofthejars</groupId>
<artifactId>nosqlunit-mongodb</artifactId>
<version>${nosqlunit.veresion}</version>
  <scope>test</scope>
  <exclusions>
      <exclusion>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      </exclusion>
      <exclusion>
      <groupId>com.github.fakemongo</groupId>
      <artifactId>fongo</artifactId>
      </exclusion>
      <exclusion>
      <groupId>org.mongodb</groupId>
      <artifactId>mongo-java-driver</artifactId>
      </exclusion>
  </exclusions>
</dependency>
</dependencies>
</project>

Со стороны разработчиков с открытым исходным кодом , создание двух вариантов пакета для потребления с зависимостями и без них может сделать мир лучше. В этом заключается разница между «предоставленной» областью maven и областью «compile» по умолчанию. Apache Maven Shade Plugin может быть использован для создания версии с зависимостями, которые будут использоваться, при этом не может возникнуть конфликтов вместе с версией, которая не зависит от версии артефакта и может использоваться без конфликтов версий.

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

Чтобы проверить наличие устаревших зависимостей и плагинов, а также обновить их контролируемым образом (вручную), можно выполнить:

В качестве альтернативы можно позволить плагину обновлять версии, выполнив следующее

Эта последняя команда mvn, которой я собираюсь поделиться, является бонусом для преданного читателя. Это позволяет безболезненно менять версии проекта и его модулей: