Maven应用手册

没加载出来就reimport，这个时候clean和install没用，那是编译安装项目的。

• reimport干了什么？

结合idea的maven教程

父子模块

子模块不需要groupId

• ruoyi中父模块还添加了子模块的依赖，，，

先安装父再是子？dubbo官网案例：
为了成功编译服务端、消费端模块，需要先在本地打包安装 dubbo-samples-spring-boot-interface 模块。

./mvnw clean install -pl 1-basic/dubbo-samples-spring-boot
./mvnw clean install -pl 1-basic/dubbo-samples-spring-boot/dubbo-samples-spring-boot-interface

Maven多模块开发

曾经我们在一个应用（一个war or jar）中划分出包(层是以包的层次结构划分的)。随着项目体积的逐渐增大，项目结构逐渐横向扩张变得臃肿（短粗）：

• 单个java文件逐渐变得很长，同一包下的文件变得很多，但项目结构已定，改变结构很费功夫；
• pom.xml中的依赖列表也越来越长，到后来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引入。甚至出现了一个依赖有多个版本存在。
• 这个应用可能需要有一个前台和一个后台管理端，你发现大部分dao，一些service，和大部分util在其他应用中可以用；
  • 如果其他项目不能引用这些代码，则不得不重写一遍；
• build整个项目的时间越来越长，尽管你只是一直在web层工作，但你不得不build整个项目。
• 某个模块，比如util，你只想让一些经验丰富的人来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不能达到你的要求。
• 你不得不新建一个项目依赖这个WAR，这变得非常的恶心，因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，而且你根本不需要org.myorg.app.web。
  项目发展到如此庞大的水平，老一套结构已经不符合高内聚、低耦合的标准了。为了给项目“减肥”，同时进一步粒化拆分模块，我们需要“增高”，即经典的“加一层”思想。现在是以包的形式分层，再加一层就是应用之间能够互相引用（或者说依赖），也就是jar包级别之间的依赖。同时，由于传统的jar包引入方式不利于维护，pom.xml文件太长也需要拆分，我们使用maven进行分模块开发，顺便还解决了编写部分代买需要编译全部项目的问题。
  一个简单的Maven模块结构是这样的：

---- app-parent|-- pom.xml (pom)||-- app-util|        |-- pom.xml (jar)||-- app-dao|        |-- pom.xml (jar)||-- app-service|        |-- pom.xml (jar)||-- app-web|-- pom.xml (war)   

较好的描述
配置文件随意，会在作用域内按优先级生效。我猜是就近原则

• 变量的就近原则和编译原理有关系吗？是在内存中顺序寻找最近的么？但内存是可以随即存取的把。

springboot多模块简单来说，就是把按包分模块的模式，借助maven升级到jar的方式，抽象性更加强了，假如jar再升级到到war或者多个集合jar，就成微服务了，在多模块jar模式下可以将某个jar拿出来对外共用，能大大提高代码复用率与开发效率。
https://zhuanlan.zhihu.com/p/345682526

父模块

创建时选择：
maven pom
不以springboot为父项目的子模块需要加入这个依赖

            <!-- SpringBoot的依赖配置--><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-dependencies</artifactId><version>2.5.9</version><type>pom</type><scope>import</scope></dependency>

声明包含的子模块，并把自己打包成pom

    <modules><module>ruoyi-admin</module><module>ruoyi-framework</module><module>ruoyi-system</module><module>ruoyi-quartz</module><module>ruoyi-generator</module><module>ruoyi-common</module></modules><packaging>pom</packaging>

属性

定义属性，如版本号等，可以自定义标签。

    <properties><ruoyi.version>4.7.2</ruoyi.version><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding><project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding><java.version>1.8</java.version><maven-jar-plugin.version>3.1.1</maven-jar-plugin.version><!-- 等等等等 --></properties>

在后面用${}取出来用。在子模块中也可以使用父模块的属性。

<plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><version>2.1.1.RELEASE</version><configuration><fork>true</fork> <!-- 如果没有该配置，devtools不会生效 --></configuration><executions><execution><goals><goal>repackage</goal></goals></execution></executions></plugin>

子模块

创建时选择： maven project
一个通用模块，其他模块需要的时候在pom.xml中依赖他就行；实体类、注解、配置类、异常、util等都在这里

注：父模块中导入的依赖，子模块的pom.xml中依然需要编写配置（但可以省略父模块中已经声明的版本号）。
可以省略的（默认导入的）是通过<dependendcy>标签依赖的模块中的依赖。
如果想要排除部门这些默认导入的模块，要指定exclusive

模块版本modelVersion和父工程版本不一样（4.0.0和4.7.2）

若依里，通用的在common里，主要业务在framework里。admin就光controller层？其他模块依赖common模块，common没有依赖其他，不然会循环依赖。admin不需要指明依赖common，因为依赖了依赖common的许多模块。（父工程下的大哥）

插件

maven 打包问题（repackage failed: Unable to find main class）

问题背景：今天用spring boot做了一个公共模块，需要打成jar包，让其他项目引用，但打包的时却提示缺少主类，但是我这一个公共模块，本来就没写主类。

错误信息：repackage failed: Unable to find main class

问题原因为使用spring boot项目，用的maven插件为

<plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><version>2.2.9.RELEASE</version></plugin>
</plugins>

用此插件打包时候会默认寻找签名是public static void main(String[] args)的方法，没有所以报错，
可以修改配置解决此问题。配置如下：

<build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><configuration><skip>true</skip></configuration></plugin></plugins></build>

或者直接修改maven插件，改用apache的maven插件，配置如下：

 <plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId>
</plugin>

• ruiyi-cloud顶级父模块为什么要两个插件都用？
  • 虽然把boot的部分排除Repackage了

   <build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><configuration><source>${java.version}</source><target>${java.version}</target><encoding>${project.build.sourceEncoding}</encoding></configuration></plugin></plugins><pluginManagement><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><version>${spring-boot.version}</version><executions><execution><goals><goal>repackage</goal></goals></execution></executions></plugin></plugins></pluginManagement></build>

spring-boot-maven-plugin

引入springboot的方式

parent
dependiences
需要注意的是,之所以引入各starter、相关依赖的时候都不写版本，因为都有统一的父模块来管理版本；
无论是以springboot-parent为父模块，还是以包含的springboot-dependience的模块为父模块；在maven种，想省略版本号都是子项目；

https://blog.csdn.net/changerzhuo_319/article/details/99710393
https://blog.csdn.net/changerzhuo_319/article/details/99710872