Объявить зависимость в разделе <dependencyManagement> даже если зависимость, не используемая везде?

В многомодульном проекте я помещаю все общие зависимости в элемент родительского pom.xml. Я не уверен, что это было бы наилучшей практикой, если бы модули не были связаны с одним и тем же проектом.

Следующий вопрос о. Если я объявлю Log4J в разделе родительского объекта, а подпроект не будет его использовать, будет ли он включен?

Нет. Управление зависимостями устанавливает только версию по умолчанию и, возможно, область видимости (я видел, что оба варианта кажутся унаследованными и не наследуются, поэтому вам нужно будет найти его самостоятельно). Чтобы включить зависимость в дочерний модуль, вам необходимо объявить ее как зависимость модуля и опустить элемент версии. Вы можете переопределить значение по умолчанию в дочернем модуле, просто включив номер версии в элемент зависимости POM дочернего модуля.

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

В данном случае да и нет.

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

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

Если у вас есть родительский проект, вы можете объявить все зависимости и их версии в разделе dependencyManagement родительского pom. Это не означает, что все проекты будут использовать все эти зависимости, это означает, что если проект действительно объявляет зависимость, он унаследует конфигурацию, поэтому ему нужно только объявить groupId и artifactId зависимости. Вы даже можете объявить свои дочерние проекты в родительском dependencyManagement, не вводя цикл.

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

Например, если у вас 4 проекта, parent , core , ui и utils , вы можете объявить все внешние зависимости и внутренние версии проекта в родительском. Затем дочерние проекты наследуют эту конфигурацию для любых объявляемых ими зависимостей. Если все модули должны иметь одну и ту же версию, их можно даже объявить как свойства в родительском элементе.

Пример родительского объекта следующий:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>name.seller.rich</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>commons-io</groupId>
        <artifactId>commons-io</artifactId>
        <version>1.4</version>
      </dependency>
      <dependency>
        <groupId>name.seller.rich</groupId>
        <artifactId>ui</artifactId>
      <version>${project.version}</version>
      </dependency>
      <dependency>
        <groupId>name.seller.rich</groupId>
        <artifactId>core</artifactId>
        <version>${project.version}</version>
      </dependency>
      <dependency>
        <groupId>name.seller.rich</groupId>
        <artifactId>utils</artifactId>
        <version>${project.version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <modules>
    <module>utils</module>
    <module>core</module>
    <module>ui</module>
  </modules>
</project>

И проекты utils, core и ui наследуют все соответствующие версии. utils:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>name.seller.rich</groupId>
  <artifactId>utils</artifactId>
  <!--note version not declared as it is inherited-->
  <parent>
    <artifactId>parent</artifactId>
    <groupId>name.seller.rich</groupId>
    <version>1.0.0</version>
  </parent>
  <dependencies>
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
    </dependency>
  </dependencies>
</project>

core:

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>name.seller.rich</groupId>
<artifactId>core</artifactId>
<parent>
  <artifactId>parent</artifactId>
  <groupId>name.seller.rich</groupId>
  <version>1.0.0</version>
</parent>
<dependencies>
  <dependency>
    <groupId>name.seller.rich</groupId>
    <artifactId>utils</artifactId>
  </dependency>
</dependencies>

ui:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>name.seller.rich</groupId>
  <artifactId>ui</artifactId>
  <parent>
    <artifactId>parent</artifactId>
    <groupId>name.seller.rich</groupId>
    <version>1.0.0</version>
  </parent>
  <dependencies>
    <dependency>
      <groupId>name.seller.rich</groupId>
      <artifactId>core</artifactId>
    </dependency>
  </dependencies>
</project>