paint-brush
Dependency Management in Microservice Architecture: Creating Your Own Parent POMby@gromspys
1,081 reads
1,081 reads

Dependency Management in Microservice Architecture: Creating Your Own Parent POM

by Sergei KorneevOctober 25th, 2023
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Simplify version management in microservices with a custom parent POM, ensuring consistent library versions across projects.
featured image - Dependency Management in Microservice Architecture: Creating Your Own Parent POM
Sergei Korneev HackerNoon profile picture


Often, in microservice architecture, there are problems related to updating versions of libraries or adding them. When working on a project for a long time, you may encounter that different microservices use different versions of the same library, and its upgrade may be delayed due to conflicts. In this article, I would like to describe one of the ways to solve these problems.


This article only describes the solution to the problem and does not cover transitive dependencies and how to work with them.

Use your own parent pom.

In most cases, existing dependency builds (like spring-boot-starter-parent or spring-boot-dependencies directly) are used in pom files as parent. But what if several microservices need to override a version of one of the dependencies or add a dependency that is not in the build?


In this case, it is better to create your own parent pom file. This will help to maintain the same library versions in all microservices. All you need to do is keep your parent pom version up to date rather than having to resolve conflicts in each microservice separately. This approach seems obvious, but for some reason, many people neglect it.


Making your own parent pom is quite simple using dependency management. You can also import existing dependency builds. It is most convenient to put library versions into variables. This will make it easier to override the dependency version in a particular microservice in exceptional cases.


<properties>
  <java.version>17</java.version>
  <json.version>20231013</json.version>
  <spring-parent.version>3.1.5</spring-parent.version>
</properties>
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-parent</artifactId>
      <version>{json.version}</version>
    </dependency>
  </dependencies>
</dependencyManagement>


In the case of plugins, you can also control their versions:


<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>org.jsonschema2pojo</groupId>
        <artifactId>jsonschema2pojo-maven-plugin</artifactId>
        <version>${jsonschema2pojo.version}</version>
      </plugin>
    </plugins>
  </pluginManagement>
</build>


To use a parent pom in a microservice, you need to publish it to your local maven repository with the mvn install command (or to another repository such as Nexus). Then you need to specify the parent in your microservice and add dependencies without specifying versions:


<parent>
  <groupId>com.example</groupId>
  <artifactId>base-pom</artifactId>
  <version>0.0.1-SNAPSHOT</version>
</parent>
<dependencies>
  <dependency>
    <groupId>org.json</groupId>
    <artifactId>json</artifactId>
  </dependency>
</dependencies>


This way, developers don't have to think about which version to use when adding dependencies to a microservice.