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 类,它的工作原理如下: 简...
- 下一篇
初学Docker容器网络不得不看的学习笔记
【技术沙龙002期】数据中台:宜信敏捷数据中台建设实践|宜信技术沙龙 将于5月23日晚8点线上直播,点击报名 一、关于Docker Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从Apache2.0协议开源。 Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口(类似 iPhone 的 app),更重要的是容器性能开销极低。 因为对比传统虚拟机有启动快、性能提升、运维成本等等绝对优势,越来越受开发运维童鞋的青睐。 二、关于Docker网络模式分类 1、bridge模式,--net=bridge(默认) 2、host模式,--net=host 3、container模式 使用–net =container:指定容器名 4、none模式,--net=none 5、用户自定义模式 三、关于Docker网络模式详解 3.1 bridge模式 Docker网络的默认模式,在docker run启动容器的时候,如果不加--net参数,就默认采用这种网...
相关文章
文章评论
共有0条评论来说两句吧...