父 pom 和微服务

java maven microservices

2022-09-01 13:10:32

我们有几个项目是微服务，每个项目都是独立的（在单独的spring boot服务器上运行，公开休息服务，使用单独的DB模式......
我们使用 maven 来管理依赖关系。

让父 pom 将每个微服务声明为模块是一个好主意吗？因此，帮助管理常见的依赖项（例如，每个项目中都使用lib servlet-api witch，以删除所有这些依赖项，并仅在父pom中声明它）

答案 1

多模块父pom的“问题”在于，如果没有复杂的配置文件，它会将模块锁定在同一发布周期中（假设您正在使用发布插件，您应该这样做）。

我与 Maven 合作的方式是有一个父 pom，它声明：

常见依赖项（日志记录 API、JUnit 等）。
常用插件。
依赖项管理部分中的所有依赖项。
插件管理部分中的所有插件。

每个模块都将父 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:compilejunit:junit:4.11:testcommons-lang:commons-lang:2.6:compile
具有插件org.apache.maven.plugins:maven-assembly-plugin:2.4

答案 2

我会避免父 pom 中的依赖关系。如果你的一个（独立的）微服务想要其他东西，这很尴尬。让父级知道每个微服务是很奇怪的。

您可以坚持使用依赖关系管理，但如果需要，可以建议默认版本/范围。父 pom 非常方便定义插件、存储库等。

相反，我会将一组通用的依赖项分组到一个特定的工件中，该工件可能只是具有依赖项的单个pom。然后你可以依靠，比如说“com.example/common-db-dependencies/1.2”来包含一组标准的数据库依赖关系，比如hibernate、apache derby和JPA规范。（或您正在使用的任何内容）。不使用 JPA/SQL 的服务可以一起避免这种依赖关系。

不过，不要纠缠自己。如果您尝试涵盖每种情况，则很容易使依赖关系结构过度工作。因此，只尝试标准化真正被大多数服务使用的东西。