Проблема № 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 : display-dependency-updates
- Версии mvn : display-plugin-updates
- Версии mvn : display-property-updates
В качестве альтернативы можно позволить плагину обновлять версии, выполнив следующее
Эта последняя команда mvn, которой я собираюсь поделиться, является бонусом для преданного читателя. Это позволяет безболезненно менять версии проекта и его модулей: