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 need to override a version of one of the dependencies or add a dependency that is not in the build? microservices 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 command (or to another repository such as Nexus). Then you need to specify the parent in your microservice and add dependencies without specifying versions: mvn install <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. Useful links Example parent pom file Documentation

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Dependency Management in Microservice Architecture: Creating Your Own Parent POM

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Code Sharing in Microservice Architecture: Creating Your Own Common Library

Code Sharing in Microservice Architecture: Creating Your Own Common Library

Getting Started With Maven - A Beginner's Guide to Efficient Java Build Management

Golang in Machine Learning

Embracing Node.js's Built-in Test Runner

3 Simple Tips for Beginners Using Autofac in C#

Code Sharing in Microservice Architecture: Creating Your Own Common Library

Code Sharing in Microservice Architecture: Creating Your Own Common Library

Getting Started With Maven - A Beginner's Guide to Efficient Java Build Management

Golang in Machine Learning

Embracing Node.js's Built-in Test Runner

3 Simple Tips for Beginners Using Autofac in C#

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps