If Maven's dependency is not handled properly, it often leads to some problems, which is very annoying. Today I'd like to share with you a dependency related problem that you may have encountered before.

Problem background

There is an ES search project, which is still in good condition at the beginning. After a while, it is found that the startup times are wrong. After reading Git submission log, I haven't changed it. The magic code world.

The error is shown in the figure below. It is obvious that the error is often encountered. It must be a version dependent problem.

6.8.7. At the beginning of the test, it was normal, which suddenly failed. I looked at the dependency of the current project and found that it became 6.4.3. So we can't find the CountRequest class.

Cause of the problem

So, it should be that where there is version limitation in my project, which covers version 6.8.7 defined by Kitty spring cloud starter elastic search.

No corresponding configuration was found in the parent pom of the project. The only possible one is Spring Boot.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.6.RELEASE</version>
    <relativePath />
</parent>

The 6.4.3 configuration was found in spring boot dependencies.

<elasticsearch.version>6.4.3</elasticsearch.version>
<dependency>
  <groupId>org.elasticsearch</groupId>
  <artifactId>elasticsearch</artifactId>
  <version>${elasticsearch.version}</version>
</dependency>
<dependency>
  <groupId>org.elasticsearch.client</groupId>
  <artifactId>transport</artifactId>
  <version>${elasticsearch.version}</version>
</dependency>
<dependency>
  <groupId>org.elasticsearch.distribution.integ-test-zip</groupId>
  <artifactId>elasticsearch</artifactId>
  <version>${elasticsearch.version}</version>
  <type>zip</type>
</dependency>
<dependency>
  <groupId>org.elasticsearch.plugin</groupId>
  <artifactId>transport-netty4-client</artifactId>
  <version>${elasticsearch.version}</version>
</dependency>
<dependency>
  <groupId>org.elasticsearch.client</groupId>
  <artifactId>elasticsearch-rest-client</artifactId>
  <version>${elasticsearch.version}</version>
  <exclusions>
    <exclusion>
      <artifactId>commons-logging</artifactId>
      <groupId>commons-logging</groupId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.elasticsearch.client</groupId>
  <artifactId>elasticsearch-rest-high-level-client</artifactId>
  <version>${elasticsearch.version}</version>
</dependency>

We all know that if the dependency management in the parent pom defines the version, the child modules can directly rely on the version of the parent pom without specifying the version. Here we use the version defined by the top-level parent pom because there is no mandatory specification.

The following figure shows our pom dependency:

Problem solving

Define the version directly in the POM of the project, which takes precedence over the definition of the parent POM, so that we can force the version we need. Only in Kitty cloud- search.pom Can be defined in.

<dependency>
    <groupId>com.cxytiandi</groupId>
    <artifactId>kitty-spring-cloud-starter-elasticsearch</artifactId>
    <exclusions>
        <exclusion>
            <artifactId>elasticsearch-rest-high-level-client</artifactId>
            <groupId>org.elasticsearch.client</groupId>
        </exclusion>
        <exclusion>
            <groupId>org.elasticsearch.client</groupId>
            <artifactId>elasticsearch-rest-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
    <version>6.8.7</version>
    <exclusions>
        <exclusion>
            <artifactId>elasticsearch-rest-client</artifactId>
            <groupId>org.elasticsearch.client</groupId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-client</artifactId>
    <version>6.8.7</version>
</dependency>

This can solve the problem. I don't think it's very good all the time.

If you want to avoid this problem, unless we use the already defined version of spring boot, it is consistent, but there will always be some special requirements. Although you have defined that ES will use 6.4.3 in the 2.1.6.RELEASE version of spring boot, I still want to use other versions which are quite common.

Another way is if there is a unified development framework within the company, you can define dependencies to manage the version of the framework, directly copy the content of spring boot dependencies, and then change it elasticsearch.version Finally, you can directly use your custom dependencies in the project.

About the author: Yin Ji Huan, a simple technical enthusiast, "Spring Cloud micro Service - full stack technology and case analysis", "Spring Cloud micro service portal introduction and promotion" author, official account of the public apes. Welcome to join us.