Maven应用手册

Tina_Run_润

已于 2024-03-11 00:06:26 修改

阅读量1.2k

点赞数 28

文章标签： maven java

于 2024-01-22 23:30:55 首次发布

本文链接：https://blog.csdn.net/qq_44915801/article/details/135760737

版权

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

结合idea的maven教程

生命周期

在这里插入图片描述

• clean：清除当前工程编译后生成的文件（即删除target整个目录）；

• validate：对工程进行基础验证，如工程结构、pom、资源文件等是否正确；

• compile：对src/main/java目录下的源码进行编译（会生成target目录）；

• test：编译并执行src/test/java/目录下的所有测试用例；

• package：将当前项目打包，普通项目打jar包，webapp项目打war包；

• verify：验证工程所有代码、配置进行是否正确，如类中代码的语法检测等；

• install：将当前工程打包，然后安装到本地仓库，别人可通过GAV导入；

• site：生成项目的概述、源码测试覆盖率、开发者列表等站点文档（需要额外配置）；

• deploy：将当前工程对应的包，上传到远程仓库，提供给他人使用（私服会用）。

上述便是九个周期阶段命令的释义，而Maven总共划分了三套生命周期：

主要看default这套，该生命周期涵盖了构建过程中的检测、编译、测试、打包、验证、安装、部署每个阶段。注意一点：同一生命周期内，执行后面的命令，前面的所有命令会自动执行
比如现在执行一条命令：

mvn test
test命令位于default这个生命周期内，所以它会先执行validate、compile这两个阶段，然后才会真正执行test阶段。同时，还可以一起执行多个命令，如：

mvn clean install
这两个命令隶属于不同的周期，所以会这样执行：先执行clean周期里的pre-clean、clean，再执行default周期中，validate~install这个闭区间内的所有阶段。

从上面不难发现，default是Maven的核心周期，但其实上面并没有给完整，因为官方定义的default一共包含23个小阶段，上面的图只列出了七个核心周期，对详细阶段感兴趣的可以自行了解。

Maven中只定义了三套生命周期，以及每套周期会包含哪些阶段，而每个阶段具体执行的操作，这会交给插件去干，也就是说：Maven插件会实现生命周期中的每个阶段，这也是大家为什么看到IDEA的Lifecycle下面，还会有个Plugins的原因：

父子模块

子模块不需要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

依赖冲突

2.1、依赖冲突
依赖冲突是指：在Maven项目中，当多个依赖包，引入了同一份类库的不同版本时，可能会导致编译错误或运行时异常。

自动解决冲突问题
①层级优先原则，Maven会根据依赖树的层级，来自动剔除相同的包，层级越浅，优先级越高。
②声明优先原则，同层级出现包冲突时，先声明的会覆盖后声明的，为此后者会被剔除。
配置优先原则，同级出现不同版本的相同类库时，后配置的会覆盖先配置的。
Maven如果无法自动解决冲突问题，会在构建过程中抛出异常并提供相关信息，这时大家可以根据给出的信息，手动排除指定依赖。