Родительский микрофон и микросервисы

Ответ 1

"Проблема" с многомодульным родительским pom заключается в том, что без сложных профилей он блокирует модули в одном и том же периоде выпуска (при условии, что вы используете Release Plugin, который вы должны быть).

Как я работаю с Maven, это иметь родительский pom, который объявляет:

• общие зависимости (API протоколирования, JUnit и т.д.).
• общие плагины.
• все зависимости в разделе dependencyManagement.
• все плагины в разделе pluginManagement.

Каждый модуль делит родительский pom как его родительский, но родитель ничего не знает о модулях.

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

Например, родительский элемент может выглядеть так:

<project>

  <groupId>com.example</groupId>
  <artifactId>parent</artifactId>
  <version>1.0.00-SNAPSHOT</version>

  ...

  <dependencies>

    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.7</version>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>            

  </dependencies>

  <dependencyManagement>

    <dependency>
      <groupId>commons-lang</groupId>
      <artifactId>commons-lang</artifactId>
      <version>2.6</version>
    </dependency>        

    <dependency>
      <groupId>commons-collections</groupId>
      <artifactId>commons-collections</artifactId>
      <version>2.1</version>
    </dependency>

  </dependencyManagement>

  <plugins>

    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.1</version>
      <configuration>
        <source>1.8</source>
        <target>1.8</target>
      </configuration>
    </plugin>

  <plugins>

  <pluginManagement>

    <plugins>

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-assembly-plugin</artifactId>
        <version>2.4</version>
        <configuration>
          <appendAssemblyId>false</appendAssemblyId>
          <descriptors>
            <descriptor>src/main/assembly/assembly.xml</descriptor>
          </descriptors>
        </configuration>
        <executions>
          <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
              <goal>single</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

    </plugins>

  </pluginManagement>

</project>

И модуль может выглядеть так:

<project>

  <parent>
    <groupId>com.example</groupId>
    <artifactId>parent</artifactId>
    <version>1.0.00-SNAPSHOT</version>
  </parent>

  <groupId>com.example</groupId>
  <artifactId>module</artifactId>
  <version>1.0.00-SNAPSHOT</version>

  <dependencies>

    <dependency>
      <groupId>commons-lang</groupId>
      <artifactId>commons-lang</artifactId>          
    </dependency>        

  </dependencies>

  <plugins>

    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-assembly-plugin</artifactId>
    </plugin>

  </plugins>

</project>

Модуль будет:

• имеют зависимости от org.slf4j:slf4j-api:1.7.7:compile, junit:junit:4.11:test и commons-lang:commons-lang:2.6:compile.
• имеет плагин org.apache.maven.plugins:maven-assembly-plugin:2.4

Ответ 2

Я бы избегал зависимостей в родительском pom. Это неудобно, если один из ваших (независимых) микросервисов захочет какие-то другие вещи. Странно знать родителя о каждом микросервисе.

Вы можете придерживаться управления dependencyManagement, хотя предлагаете варианты/области по умолчанию, если хотите. Родительский pom, тем не менее, очень удобен для определения плагинов, репозиториев и т.п.

Вместо этого я бы сгруппировал общий набор зависимостей в конкретный артефакт (ы), который может быть только одним pom с зависимостями. Тогда вы можете зависеть, скажем, "com.example/common-db-dependencies/1.2", чтобы включить стандартный набор зависимостей базы данных, например, hibernate, apache derby и спецификации JPA. (или что вы используете). Служба не использует JPA/SQL, чтобы избежать этой зависимости все вместе.

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

Ответ 3

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

Некоторые конфигурации, например, говорят, что ваш репозиторий или версия конфигурации и т.д. могут быть общими.