background

  • Recently, according to the company’s demand, we have developed a two-party library package shared by the company. Here popular science below: what is called one party library, two party library, three party library. Made in AlibabaTaishan edition “Java Development Manual” Attachment 2: Explanation of proper nounsThis is mentioned in the chapter
  • One-party library: libraries (JAR packages) that the subproject modules within the project depend on

Depends on the internal of the project
commonModules, which typically define some basic functionality that all modules use, such as
Global exception codes, distributed locks, unified response entities, and so on

  • Second party library: the library (JAR package) that is released internally to the central warehouse and can be relied on by other applications within the company.

In Internet companies there are usually divisions, and then there is a division called
Base Department/Base CenterThis division may provide some of the company’s basic libraries, such as EG: MQ-related unified AMQP operations, RPC-related unified Dubbo operations, etc. Eventually these are pushed to the Maven repository as JARs (a proprietary Maven repository needs to be set up internally). Now is the era of Spring Boot. If the company uses the system of Spring Boot, these JAR packages are usually provided in the way of starter. By using the automatic assembly mechanism of Spring Boot, other business units can easily connect with each other.

  • Third-party libraries: open source libraries outside the company (JAR packages)

Common springboot, mybatis

Since the company is using the SpringBoot related technology stack internally, the two-party library package I developed is provided as a starter. The whole docking process only needs two steps:

1. The two-party library package needs to be pushed to the Maven repository

2. Other divisions only need to add the Maven coordinates of the two-square library package

There are a few minor details here: the two-party library package is a project project and will also rely on some two-party and three-party libraries. In general, the scope of the JARs that the library relies on internally is set to the provider (the default system does not couple the JARs that the library relies on internally with the project of the interface), but it is not uncommon for a dependency to be added to the interface, so it is necessary to add a dependency that matches the version of the interface. Next, you’ll see how to find the right version of Spring-Kafka with the introduction of SpringBoot as an example.

Why can’t Maven find a version of Spring-Kafka?

  • Consider this scenario: I developed a two-sided library package that uses SpringBoot as the technology stack, and one of the functions I developed internally relies on Spring-Kafka’s three-way library. It is well known that SpringBoot provides an extremely comfortable development environment, and when we introduced the SpringBoot framework, all tripartite library dependencies were defined internally in accordance with the current version. So, let’s say we want to introduce the Spring-Kafka module by adding the following coordinates to the pom.xml file:

    <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> The < version > 2.4.4 < / version > < relativePath / > <! -- lookup parent from repository --> </parent> <! -- just add the following coordinates, Do not need to specify version - > < dependencies > < the dependency > < groupId > org. Springframework. Kafka < / groupId > <artifactId>spring-kafka</artifactId> </dependency> </dependencies>

When we introduced the Spring-Kafka module above, we could have used it without specifying version. This is because Spring-Kafka dependencies are defined in dependencyManagement within spring-boot-starter-parent. As a child module, the dependency is simply introduced. The version number will be inherited by default from the parent project. Maven can’t find the spring-kafka version if it uses SpringBoot 1.4.1. Release: SpringBoot 1.4.1. Release SpringBoot 1.4.1.

<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> The < version > 1.4.1. RELEASE < / version > < relativePath / > <! -- lookup parent from repository --> </parent> <! -- just add the following coordinates, Do not need to specify version - > < dependencies > < the dependency > < groupId > org. Springframework. Kafka < / groupId > <artifactId>spring-kafka</artifactId> </dependency> </dependencies>

The reason for this is that there is no internal dependency on spring-kafka in spring-boot-starter-parent, so you cannot inherit the version defined by the parent class, and eventually Maven will tell you that the corresponding version cannot be found. The docking side has been developing normally with SpringBoot 1.4.1. Release. Is it possible to upgrade SpringBoot to integrate with your library? Therefore, we need to find the appropriate version of Spring-Kafka for the join side.

Spring Boot 1.4.1. Release: SpringBoot 1.4.1. Release: SpringBoot 1.4.1. Release: SpringBoot 1.4.1

  • One of the easiest ways to do this is to find the POM file definition in IDEA. This is one way. However, as a two-party library provider, you may often have to deal with the subsequent issue of not being able to introduce Spring-Kafka due to different versions of SpringBoot on the business side. Do we need to update Maven’s version of SpringBoot locally every time we download it from Maven and then use IDEA to view it? This is obviously a bit of a hassle.
  • Another option is to find the official documentation for SpringBoot 1.4.1.RELEASE, but there is no reference to Kafka even in the Maven dependencies. Chances are that Kafka is not integrated with this RELEASE.

  • Another way is: refer to this link https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/. The 1.4.1 RELEASE version of SpringBoot depends on which libraries SpringBoot depends on internally. The 1.4.1 RELEASE version depends on which libraries SpringBoot depends on internally.

    1. Positioning version

    2. View the dependent POM file

    3. Good at searching (search Spring-Kafka)

      As you can see, there is no internal dependency on Spring-Kafka in Spring Boot 1.4.1.RELEASE. What should I do now? Updates to the SpringBoot version and search further, and eventually you will find that internal dependencies on Spring-Kafka are starting to emerge with the 1.5.0.RELEASE. Therefore, we can try to introduce the lookup version 1.1.2.RELEASE into Maven

      The corresponding pOM.xml file is

      <dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> < version > 1.1.2. RELEASE < / version > < / dependency >
In this scenario, introducing the **1.1.2.RELEASE** fixes the problem, and the docking system works fine. Maybe it doesn't work in other situations, but it's one way to do it, We can find each springboot version through the https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/ link internal rely on third-party libraries, This is much more convenient than changing the version number in IDEA and then downloading the corresponding version.

Third, summary

  • Another solution for locating dependent versions, if you find my article useful, welcome to thumb up, bookmark and follow.
  • I’m a slow walker, but I never walk backwards