maven项目在实践中的构建管理之路
前言
最近一个月参与了公司几个项目的脚手架构建,适当总结下经验。之前见过太多项目依赖,构建,管理混乱不堪,导致后续的维护性差,甚至出现由此引发的事故。当时就有一个规范管理的想法。
依赖管理
依赖管理,其实就是依赖范围的管理。这里我叫他 依赖池
。也就是 所有相关项目的依赖只能从这个池子里拿,不能超出其范围。池子里的依赖我们定义为都是久经考验的同志。以maven工程为例,我们可以定义 一个名为ooxx-dependencies
的 pom
类型的工程。这里用来存放我们经过技术选型并测试通过的依赖。每次依赖变动发布都要有新的版本号。也就是 依赖池
的迭代一定要以版本号为标志,多版本并行。
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-dependencies</artifactId>
<version>1.0.0.RELEASE</version>
<name>ooxx dependencies</name>
<description>the root dependencies</description>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
<springboot.version>2.1.5.RELEASE</springboot.version>
<spring-boot-admin.version>2.1.4</spring-boot-admin.version>
<springSecurityJwt.version>1.0.10.RELEASE</springSecurityJwt.version>
<mysql.version>5.1.47</mysql.version>
<hikari.version>3.2.0</hikari.version>
<hutool.version>4.5.5</hutool.version>
<mybatisplus.version>3.1.1</mybatisplus.version>
<wexin-pay.version>3.2.0</wexin-pay.version>
<wexin-miniapp.version>3.2.0</wexin-miniapp.version>
<swagger.version>2.9.2</swagger.version>
</properties>
<distributionManagement>
<repository>
<id>nexus</id>
<name>Releases</name>
<url>http://url/repository/maven-releases</url>
</repository>
<snapshotRepository>
<id>nexus</id>
<name>Snapshot</name>
<url>http://url/repository/maven-snapshots</url>
</snapshotRepository>
</distributionManagement>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>${springboot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-dependencies</artifactId>
<version>${spring-boot-admin.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>${springboot.version}</version>
<!-- 排除Tomcat依赖 -->
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.springframework.security</groupId>
<artifactId>spring-security-jwt</artifactId>
<version>${springSecurityJwt.version}</version>
</dependency>
<dependency>
<groupId>com.zaxxer</groupId>
<artifactId>HikariCP</artifactId>
<version>${hikari.version}</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql.version}</version>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-boot-starter</artifactId>
<version>${mybatisplus.version}</version>
</dependency>
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-generator</artifactId>
<version>${mybatisplus.version}</version>
</dependency>
<!--swagger2-->
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger2</artifactId>
<version>${swagger.version}</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-ui</artifactId>
<version>${swagger.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
然后,我们根据业务会定义一个parent项目,这个项目同样是pom
工程,区别于依赖池的是, 依赖池基于技术栈而不关注业务,parent关注于业务,不同业务application 依赖不同的parent,parent 来定义具体业务的module层次划分。当然parent 必须从依赖池构建。可能例子更直观, 我们有一个项目,模块分为:1.后台管理模块 2.app接口模块 3.通用依赖模块 4.数据层模块 5.app 启动模块 可以结合上面例子进行如下构建parent
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-parent</artifactId>
<version>1.0.0</version>
<packaging>pom</packaging>
<name>parent</name>
<description>the parent</description>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<java.version>1.8</java.version>
<ooxx.version>1.0.0</ooxx.version>
<ooxx-dependencies.version>1.0.0.RELEASE</ooxx-dependencies.version>
</properties>
<dependencyManagement>
<dependencies>
<!--依赖池 -->
<dependency>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-dependencies</artifactId>
<version>${ooxx-dependencies.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!--数据层模块 -->
<dependency>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-db</artifactId>
<version>${ooxx.version}</version>
</dependency>
<!--通用依赖模块 -->
<dependency>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-common</artifactId>
<version>${ooxx.version}</version>
</dependency>
<!-- 后台管理模块-->
<dependency>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-manage-api</artifactId>
<version>${ooxx.version}</version>
</dependency>
<!--app接口模块 -->
<dependency>
<groupId>com.ooxx</groupId>
<artifactId>ooxx-app-api</artifactId>
<version>${ooxx.version}</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>cn.hutool</groupId>
<artifactId>hutool-all</artifactId>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<scope>compile</scope>
</dependency>
</dependencies>
</project>
上述的具体如 app接口模块 可以直接引用依赖池中的依赖进行具体开发。
补充
同时建议 版本号 为{数字}.{说明格式}。比如1.0.0.RC、 1.0.0.GA 等用于不同的场景。pom 名称尽量 模板化 如 ooxx-parent 下的子module 命名为 ooxx-db、ooxx-app-api 之类。这样可以用maven 模板生成统一的模板项目以快速构建项目。同时达到 “见其名而知其意”的效果。因个人能力有限,不足之处或者更好的建议还望多多指教。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
线程池没你想的那么简单
前言 原以为线程池还挺简单的(平时常用,也分析过原理),这次是想自己动手写一个线程池来更加深入的了解它;但在动手写的过程中落地到细节时发现并没想的那么容易。结合源码对比后确实不得不佩服 Doug Lea 。 我觉得大部分人直接去看 java.util.concurrent.ThreadPoolExecutor 的源码时都是看一个大概,因为其中涉及到了许多细节处理,还有部分 AQS 的内容,所以想要理清楚具体细节并不是那么容易。 <!--more--> 与其挨个分析源码不如自己实现一个简版,当然简版并不意味着功能缺失,需要保证核心逻辑一致。 所以也是本篇文章的目的: 自己动手写一个五脏俱全的线程池,同时会了解到线程池的工作原理,以及如何在工作中合理的利用线程池。 再开始之前建议对线程池不是很熟悉的朋友看看这几篇: 这里我截取了部分内容,也许可以埋个伏笔(坑)。 具体请看这两个链接。 如何优雅的使用和理解线程池 线程池中你不容错过的一些细节 由于篇幅限制,本次可能会分为上下两篇。 创建线程池 现在进入正题,新建了一个 CustomThreadPool 类,它的工作原理如下: 简...
-
下一篇
MySQL8.0 - 新特性 - 安全及权限相关改进
MySQL8.0里引入了不少关于权限的改动,从这些改动可以看出来,权限管理更加的规范和遍历了,这和我们之前为rds mysql增加了大量权限管理很类似,想来Oracle也是通过这些改动为其云业务服务的吧。 本文主要简述下部分相关的权限改动,不会涉及代码实现部分。当前版本为8.0.16 Atomic ACL Statement 由于实现了新的数据词典表,所有的权限相关的信息都存储在innodb mysql tablespace里。而innodb是事务性引擎,具有ACID特性,所以对应的ACL操作也具有原子特性。 例如之前如果一个语句对多个user操作的时候,有些成功,有些会失败。而现在则是要么全部成功,要么全部失败。binlog也会在事务提交时记录到redo log里。 这里有个问题是当我们通过搭建备库的方式从5.7升级到8.0时,那些在5.7部分成功的acl操作,到了以8.0作为备库的实例上会全部失败. 关于atomic ddl 见官方文档 Role Role是一个期待已久的功能,可以认为是一组权限的集合, 你可以为多个账户赋予相同的role权限,这也使得权限的管理更加规范,大大方便了...
相关文章
文章评论
共有0条评论来说两句吧...