IDEA中多模块间依赖导入成功，但是编译时却报找不到该包：could not find artifact xxxx

Ka_bu_da

已于 2022-03-02 21:48:24 修改

阅读量1.1w

点赞数 4

文章标签： SpringBoot 模块依赖编译器版本 maven-plugin jar包打包

于 2022-03-02 10:02:55 首次发布

本文链接：https://blog.csdn.net/Ka_bu_da/article/details/123221917

版权

项目结构如下：

gulimall（父类工程）

| - - - gulimall-common（通用工具类子工程，非springboot项目）

| - - - gulimall-product（springboot子工程，依赖common、third-party工程）

| - - --gulimall-third-party（springboot子工程，依赖common工程）

问题及解决过程：
在编译gulimall-peoduct模块的时候，报错如下：显示找不到common模块的包！但是我们确实已经导入整个common模块作为其依赖。
在这里插入图片描述

1.处理common模块打包失败
在这里插入图片描述

于是我们单独编译一下common模块，找一下问题，显示如下：
在这里插入图片描述
看来编译器使用的是1.5版本，还不支持泛型，所以我们需要指定使用高版本的编译器：

这里我们可以通过在project setting中设置common模块的language level为8版本来解决问题：

同时我们可以在setting中设置Java Compiler为1.8版本：

上述方法的问题是：IDEA中Java Compiler以及项目中language level老是自动回调 (参考文章：https://blog.csdn.net/LiaoHongHB/article/details/83900387 ) 。

每当我们打开其他项目或者在pom.xml文件中引入其他依赖之后，重新运行我们项目的时候，会发现又出现了编译器版本不对的情况，为了彻底的解决这种情况，我们可以在common模块的pom.xml文件中这样设置：

<build>
        <plugins>
            <!--指定了编译器的版本-->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>

        </plugins>
    </build>

这样我们的common模块就可以编译成功了，可以看到因为我们的common模块被打包成功！
在这里插入图片描述

2.处理gulimall-product中导入common包失败

我们还是将gulimall-common调整为一个springboot的模块，然后在gulimall-product中进行打包，还是显示找不到 guli-common的jar包。

解决方法一：

（参考文章：https://zfpp25.blog.csdn.net/article/details/79656972）
因为直接对product模块打包，common并没有被打包，依赖关系无法保持。这时你要做的就是：

1.首先对项目common进行install（第一部分我们已经确保了common模块可以正常打包)。

注意:
Common打包出来的应该是不可执行的jar包(应该是一个可以被其他模块引用的jar包)，所以不要在Common的pom中定义**~~spring-boot-maven-plugin~~ **插件。因为这个SpringBoot插件会在Maven的package后进行二次打包，目的为了生成可执行jar包（这个包的名字和我们第一次打的包名字一样），如果common中定义了这个插件，会报错提示没有找到main函数。

2.这时你就可以去打包product项目了，当然打包的时候可能还是不行，这里还有一个小坑，如果还是不能进行打包的话，那么就install一下root项目，也就是总目录下的pom文件对应的install操作，这样再打包product项目基本上就没有问题了。

解决方案二：
（感觉方案一更好用些）

因为我们这里还有个gulimall-third-party的模块，这个模块是需要打包成可执行的jar包的，并且我们的common模块也是引用了这个包，我们就算不在common模块中引入spring-boot-maven-plugin插件，但是gulimall-third-party模块又怎么处理叻？

在被调用的模块pom设置为：（这里我们common根本不添加此插件，在third-party中添加下面依赖）

<plugin>
    <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-maven-plugin</artifactId>
     <version>2.1.18.RELEASE</version>
     <executions>
         <execution>
             <phase>none</phase>
         </execution>
     </executions>
     <configuration>
         <classifier>execute</classifier>
     </configuration>
 </plugin>

在调用的模块设置：（这里我们是在product中添加这个依赖）

<plugin>
     <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <version>2.3.7.RELEASE</version>
      <configuration>
          <mainClass>com.yxj.gulimall.product.GulimallProductApplication</mainClass>
      </configuration>
      <executions>
          <execution>
              <id>repackage</id>
              <goals>
                  <goal>repackage</goal>
              </goals>
          </execution>
      </executions>
</plugin>