Как настроить разрешение версии зависимостей maven? - PullRequest
0 голосов
/ 22 мая 2018

Итак, я хочу использовать диапазоны версий maven, однако правила разрешения текущей версии не соответствуют моим требованиям.Есть ли способ, возможно, выходящий из существующих плагинов maven, чтобы я мог переопределить какую версию из диапазона, который будет выбран в качестве версии зависимости?

Например, предположим, что зависимость имеет следующий диапазон:

[1.0.0, 2.0.0)

В настоящее время это может разрешить нежелательную версию или даже снимок (для этого существует проблема в Maven и все еще в процессе)

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

mvn clean verify

Я не хочу использовать плагин maven version.У нас около 50 микросервисов, мы хотим, чтобы обратно-совместимые версии выбирались автоматически, в противном случае каждый раз, когда разработчик вносит небольшие изменения, он должен запускать плагин maven version для всех приложений.

Я обнаружил DefaultVersionRangeResolver в mavenЛюбой намек или идея, как написать свой собственный преобразователь диапазона версий и включить его в Maven?Документация по этим вещам не совсем понятна.

Спасибо

Ответы [ 2 ]

0 голосов
/ 28 мая 2018

Я собираюсь ответить на решение (я) я нашел.Поэтому мы решили начать с более высокой версии, такой как 4.0.0, чтобы в нашем хранилище maven не было SNAPSHOT для этих версий.Тем не менее, кажется, что разрешение зависимостей для диапазона версий в maven иногда срабатывает и не надежно.

Для тех, кто все еще хочет переопределить поведение maven, я нашел способ после поиска в коде maven.

Вы можете создать класс следующим образом:

@Named
@Component( role = VersionRangeResolver.class )
public class SemVerRangeResolver
    implements VersionRangeResolver, Service
{
   //The content can be copied and pasted from org.apache.maven.repository.internal.DefaultVersionRangeResolver
}

После того, как вы создадите этот класс, вам нужно создать файл с именем 'components.xml' и поместить его в \src\main\resources\META-INF\plexus\components.xml

<?xml version="1.0" encoding="UTF-8"?>
<component-set>
  <components>
    <component>
      <role>org.eclipse.aether.impl.VersionRangeResolver</role>
      <role-hint>default</role-hint>
      <implementation>com.yourcomp.dependency.SemVerRangeResolver</implementation>
      <description />
      <isolated-realm>false</isolated-realm>
      <requirements>
        <requirement>
          <role>org.eclipse.aether.spi.log.LoggerFactory</role>
          <role-hint />
          <field-name>logger</field-name>
        </requirement>
        <requirement>
          <role>org.eclipse.aether.impl.MetadataResolver</role>
          <role-hint />
          <field-name>metadataResolver</field-name>
        </requirement>
        <requirement>
          <role>org.eclipse.aether.impl.SyncContextFactory</role>
          <role-hint />
          <field-name>syncContextFactory</field-name>
        </requirement>
        <requirement>
          <role>org.eclipse.aether.impl.RepositoryEventDispatcher</role>
          <role-hint />
          <field-name>repositoryEventDispatcher</field-name>
        </requirement>
      </requirements>
    </component>
  </components>
</component-set>

, затем создайте файл jar и поместите его в ваш {MAVEN_HOME}/lib/ext

Это заменит переопределитель по умолчанию для диапазона диапазонов maven, и вы можете внести любые изменения в правила для применения правил semver

0 голосов
/ 23 мая 2018

Я не думаю, что было бы разумно писать свой собственный преобразователь диапазона версий.Что вы можете сделать:

  1. Если вы действительно хотите, чтобы каждое незначительное изменение или исправление исправлялось автоматически в следующей сборке, вы можете обогатить свою команду сборки, т.е. вместо mvn clean deploy вы говорите mvn versions:update-releases ... clean deploy.
  2. Если ваши проекты тесно связаны, вы можете объединить их в один многомодульный проект.Затем вы можете собрать все вместе, и каждый модуль получит последние изменения каждого другого модуля.

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

...