一、分模块开发与设计
直接引用前面写过的
https://blog.csdn.net/weixin_51351637/article/details/128052572
二、聚合
直接引用前面写过的
https://blog.csdn.net/weixin_51351637/article/details/128052572
三、继承
直接引用前面写过的
https://blog.csdn.net/weixin_51351637/article/details/128052572
四、属性
4.1 基本介绍
经过上面的操作,我们的子模块和父模块之前有了一个良好的关系,但是在我们的父模块的内部很有可能会出现问题
比如说,同一个groupId下有不同的artifactId,很有可能会出现 artifactId不同。
或者说我们改了其中的一个版本,但是忘记改另外两个依赖的版本
如下图所示
现在我们希望出现一种机制,能够统一更改同一个groupId不同artifactId的版本信息(version),这种机制叫做属性,以后的版本信息都用这个属性的内容
4.1.1 自定义属性
等同于定义变量,方便统一维护
4.1.2 内置属性
使用Maven的内置属性,快速配置
调用格式:
${basedir}
${version}
<!--version前面可以加一个project. 这个也是可以省略的 -->
${project.version}
4.1.3 Setting属性
使用Maven配置文件setting.xml中的标签属性,用于动态配置
比如说想读取Maven安装目录中的setting.xml文件中的内容,就可使用下面的形式
调用格式:
${settings.localRepository}
4.1.4 Java系统属性
读取java系统属性
${user.home}
maven里面也可以操作
系统属性查询方式:
mvn help:system
这样执行之后就会下载许多的插件,也会有两个分区,下面是系统变量
比如我们填写这个,我们就可以获取到Java(TM) SE Runtime Environment
${java.runtime.name}
4.1.5 环境变量属性
下半区就是环境变量分区
环境变量引用前加env.
使用和4.1.4相同
4.2 定义属性
<properties>
<java.version>1.8</java.version>
<!--属性名一般自己定义,一般是技术名称加一个version -->
<spring.version>5.1.9.RELEASE</spring.version>
</properties>
4.3 使用属性
<dependencyManagement>
<dependencies>
<!--只要与org.springframework有关的都能让${spring.version}属性替换 -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
另外说明
这个时候不需要在<properties>标签中填写。我们可以看到父工程的version和我们自己引入依赖的版本一个样子的1.0-SNAPSHOT,所以Maven为我们提供了一个比较方便的东西,如果我们想在<dependencies>中的<version>使用和该pom.xml文件一个样的值,可以直接写 <version>${version}</version>
<artifactId>com.itheima</artifactId>
<groupId>ssm</groupId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<description>练习</description>
<dependencyManagement>
<dependencies>
<!--只要与org.springframework有关的都能让${spring.version}属性替换 -->
<dependency>
<groupId>com.itheima</groupId>
<artifactId>ssm_pojo</artifactId>
<!--<version>1.0-SNAPSHOT</version> -->
<version>${version}</version>
</dependency>
</dependencies>
</dependencyManagement>
但是说实话我在实习的时候看公司pom文件,并没有这么做,还是在properties中进行声明,因为公司的项目会有很多的文件,有时候我们在本地只会修改一两个工程包,其他的工程包的版本不会动。如果这个时候我们修改父工程的版本,剩下的子工程的版本都会改变,但是大部分子工程的内容是没有改变的,所以没有必要。
这种情况下在我的公司是从git上的分支再拉取自己的分支,写完代码push之前我们需要统一版本,这时候我们需要将parent工程的pom文件版本以及修改过其他工程的pom文件版本统一,没有修改的就不用动,再install(将修改后的工程下载到本地)、deploy一下,上传到git自己的分支,然后再合并到test分支进行测试(parent项目不合并)。
合并到test的时候肯定会有冲突,此时pom文件中的版本要以test分支的版本号一致,相当于又将版本改回去了
五、版本管理
5.1 SNAPSHOT与RELEASE区别
SNAPSHOT: 快照版本
东西还没做完,正在开发, 也就是未完成版
项目开发过程中,为方便团队成员合作,解决模块间相互依赖和实时更新的问题,开发者对每个模块进行构建的时候,输出的临时性版本叫快照版本(测试阶段版本)
快照版本会随着开发的进展不断地更新
RELEASE:发布版本,成品
我们之前在spring天天见到RELEASE
项目开发到进入阶段里程碑后,向团队外部发布较为稳定的版本,这种版本所对应的构建文件是稳定的,即便进行功能的后续开发,也不会改变当前发布版本内容,这种版本成为发布版本
修改完版本记得install一下,将依赖下载到仓库。
说到底这个操作都是改了一个名
5.2 工程版本号约定
六、资源配置
6.1 main资源文件对应信息
这是在父工程的pom.xml文件中统一配置,下面的资源的属性要在其他的资源文件中使用
<properties>
<jdbc.url>jdbc:mysql://localhost:3306/ssm_db</jdbc.url>
</properties>
下面是在application.yaml中配置,比如
url: ${jdbc.url}
但是我们把项目install到仓库中,查看pom文件,发现是没有解析的,那这肯定是不行的
那我们怎么解决这件事呢?
在父工程的pom.xml中的<build>构建里面定义清楚资源文件参与这种形式的使用
<build>
<!--配置资源文件对应的信息-->
<resources>
<resource>
<!--指定资源文件所对应的目录,对应不到目录依然会解析不了-->
<directory>../ssm_dao/src/main/resources</directory>
<!--指定参与这种过滤,开启对配置文件的资源加载过滤-->
<filtering>true</filtering>
</resource>
</resources>
</build>
但是现在又存在了一个新的问题,如果有很多的工程,比如controller、service、dao等都存在类似的配置文件,那岂不是要添加很多?
答案是不用的,我们可以来一个通配的格式,如下所示
<build>
<!--配置资源文件对应的信息-->
<resources>
<resource>
<!--指定资源文件所对应的目录,对应不到目录依然会解析不了-->
<directory>${project.basedir}/src/main/resources</directory>
<!--指定参与这种过滤-->
<filtering>true</filtering>
</resource>
</resources>
</build>
6.2 test资源文件对应信息
还有一种情况,就是测试类下面也会有一些配置文件,那这怎么做呢?
如下所示:
<build>
<!--配置资源文件对应的信息-->
<resources>
<resource>
<!--指定资源文件所对应的目录,对应不到目录依然会解析不了-->
<directory>${project.basedir}/src/main/resources</directory>
<!--指定参与这种过滤-->
<filtering>true</filtering>
</resource>
</resources>
<!--配置资源文件对应的信息-->
<testResources>
<testResource>
<!--指定资源文件所对应的目录,对应不到目录依然会解析不了-->
<directory>${project.basedir}/src/test/resources</directory>
<!--指定参与这种过滤-->
<filtering>true</filtering>
</testResource>
</testResources>
</build>
七、多环境开发配置
生产环境、开发环境、测试环境,在这三个不同的环境时,我们很有可能会改一下我们的配置(每次上线都需要把这些配置改一下),所以我们接下来要实现我们的配置能在多个环境运行,不用再修改配置
7.1 创建多环境
环境一般就是指生产环境、开发环境、测试环境。
<profiles>
<!--开发环境-->
<profile>
<id>dev</id>
<!--定义环境中专用的属性值,比如我们刚刚定义的jdbc-->
<properties>
<jdbc.url>jdbc:mysql://127.0.0.0:3306/ssm_db</jdbc.url>
</properties>
</profile>
<!--生产环境-->
<profile>
<id>pro</id>
<properties>
<jdbc.url>jdbc:mysql://localhost:3306/ssm_db</jdbc.url>
</properties>
</profile>
</profiles>
但是现在如果执行的话,我们的配置文件还是直接展示url: ${jdbc.url},并没有进行编译解析。
因为我们在Maven运行install的时候并没有指定环境,下面我们就指定环境
7.2 指定运行环境
-P表示指定环境
mvn install -P pro
进入公司实习之后,发现公司会使用nacos远程配置,在这个地方会指定运行的环境
我们不通过命令行,我想直接install就让环境生成,有没有办法呢?
有!我们可以设置一种环境作为默认使用
<profiles>
<!--开发环境-->
<profile>
<id>dev</id>
<!--定义环境中专用的属性值,比如我们刚刚定义的jdbc-->
<properties>
<jdbc.url>jdbc:mysql://127.0.0.0:3306/ssm_db</jdbc.url>
</properties>
<!--作为默认的使用-->
<activation>
<activeByDefault>true</activeByDefault>
</activation>
</profile>
<!--生产环境-->
<profile>
<id>pro</id>
<properties>
<jdbc.url>jdbc:mysql://localhost:3306/ssm_db</jdbc.url>
</properties>
</profile>
</profiles>