Как работать с зависимостями подпроектов в Maven

Question

Мой проект состоит из 5 подпроектов. Один - это война, а остальные 4 - банки. В основном, военному проекту нужны все 4 проекта jar и их зависимости.

Я могу сократить зависимости, чтобы получить что-то вроде war-> A-> B-> C-> D. Каждый подпроект добавляет свою долю внешних зависимостей (весна, распорки, спящий режим), так что в итоге война получает все необходимое для запуска.

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

Представьте, что мне нужно изменить одну строку кода в проекте D, не меняя ничего в зависимости от Maven. Я должен был бы переиздать проект D, но затем я должен переиздать проекты C, B, A и войны, чтобы отразить это изменение в своих файлах pom. Это может быть долгим и раздражающим, особенно если вам нужно быстро выпустить новую версию, чтобы исправить что-то в работе.

Я мог бы сделать войну зависимой от всех 4 проектов, так что тогда мне просто нужно изменить номер версии проекта D в файле war pom. Но тогда у меня есть проект A, который косвенно зависит от проекта D 1.0 и проекта войны D 1.1. Я думаю, что в этом случае победит прямая зависимость от войны, не так ли?

Это ускорило бы выпуск новой версии войны, но также запутало бы зависимость от моих подпроектов, так как они бы устарели.

Что было бы приемлемым способом справиться с этой ситуацией?

Answer 1

Нет простого ответа на вашу проблему.

Если у вас действительно есть цепочка транзитивных зависимостей (A-> B-> C-> D), то освобождение каждого модуля вверх по цепочке - неплохой вариант. Хотя это утомительно, но есть большая вероятность, что ваши вложенные зависимости являются простыми библиотеками JAR и не будут видеть изменения слишком часто. Надеюсь, вам не придется часто проходить этот процесс. Притворимся, что это будет та же самая ситуация, как если бы log4j был обновлен, и все ваши модули также должны были быть обновлены.

Еще одна вещь, которую следует учитывать, это зависимости вашей WAR. Да, Maven автоматически извлекает зависимости, но хорошей практикой является явное объявление ваших известных зависимостей, чтобы вы могли сами указать номер версии для каждого модуля. Это будет означать, что А зависит от D и других напрямую. К сожалению, если у вас есть противоречивые номера версий, как вы описали, то вы ищете проблемы на пути к классам. Однако если вам действительно нужно это сделать, maven позволяет явно исключить транзитивные зависимости:

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>my.project</groupId>
      <artifactId>module-B</artifactId>
      <version>1.0</version>
      <exclusions>
        <exclusion>
          <groupId>my.project</groupId>
          <artifactId>module-C</artifactId>
        </exclusion>
        <exclusion>
          <groupId>my.project</groupId>
          <artifactId>module-D</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>my.project</groupId>
      <artifactId>module-C</artifactId>
      <version>1.0</version>
      <exclusions>
        <exclusion>
          <groupId>my.project</groupId>
          <artifactId>module-D</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>my.project</groupId>
      <artifactId>module-D</artifactId>
      <version>1.0</version>
    </dependency>
  </dependencies>
  ...
</project>

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

Вам на самом деле нужно освобождать B, C и D независимо? Если нет, рассмотрите возможность использования файла Aggregator pom.xml в корне ваших модулей. Это позволит вам использовать версии SNAPSHOT во всех ваших модулях, а затем сразу же выпустить пакет. Именно так наша команда управляет нашим многомодульным проектом. Использование зависимостей SNAPSHOT обеспечивает использование версии, созданной JUST, когда эти артефакты необходимы.

Answer 2

Лучший ответ в наши дни - использовать gradle, который лучше всего подходит для муравьев и мавенов. Мне никогда не нравился maven, но gradle взял много общих понятий, но сделал его больше похожим на муравей в том смысле, что он гибкий, так что в gradle нет простого ответа на ваш вопрос;).

Answer 3

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

Чтобы упростить выпуск, вам может помочь maven-release-plugin .