我把公司 10 年老系统改造 Maven，真香！！

• 2020 年 9 月 23 日
• 筆記

公司有几个老古董项目，应该是 10 年前开发的了，有一个是 JSP + Servlet，有一个还用的 SSH 框架，打包用的 Ant，是有多老啊，我想在座的各位很多都没听过吧。

为了持续集成、持续部署的需要，需要把这些老古董项目全改造成 Maven 管理，下面开搞。

快速创建一个 Maven 项目

Maven Archetype 介绍

如何快速创建一个 Maven 项目，可以通过 Maven 的 Archetype 来进行创建，Archetype 是 Maven 提供的各种各样的工程模板，通过这些模板可以生成不同的 Maven 项目结构。

Maven 提供的 Archetype 列表如下：

//maven.apache.org/archetypes/index.html

这里我们选择 maven-archetype-quickstart 这个模板进行快速创建，因为它提供了一个标准的项目结构，基于这个基本项目结构可以进行后续扩展。

project
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- $package
    |           `-- App.java
    `-- test
        `-- java
            `-- $package
                `-- AppTest.java

生成 Maven 项目

1）通过 Maven 命令

Maven 提供了命令快速创建 Maven 项目：

mvn archetype:generate
-DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-quickstart
-DarchetypeVersion=1.4

命令中指定我们前面所说的 Maven Archetype：maven-archetype-quickstart 信息。

运行过程中会提示让你输入项目的 Naven 坐标信息，直到创建完成。基础部分这里不撰述了，需要完整 Maven 教程的关注公众号Java技术栈在后台回复”mvn”获取。

2）通过 IDEs

通过 IDE 也能快速创建 Maven 项目，现在 Java IDEs 都支持 Maven 或者自带 Maven 插件，下面以 Intellij IDEA 为例进行创建。

选择 maven-archetype-quickstart:

输入项目的 Naven 坐标信息：

选择 Maven 及仓库设置信息：

等待项目构建完成，如下所示：

Maven 项目重构

Maven 项目配置

项目生成后，我们就可以把原系统的文件移到新的 Maven 项目了，因生成的项目结构比较简单，Maven 提供的 maven-archetype-webapp 模板也不符合要求：

我们的项目性质又是后台系统，涉及到方方面面，所以还需要再完善其他资源目录的创建：

- src
  - main
    - java
    - resources
    - filters
    - webapp
  - test
    - java
    - resources

这是一个比较标准的 Maven Web 项目结构，我把它弄成了一个基础脚手架，还集成了各种现成的插件和功能，后面其他项目转 Maven 可以直接拿来套用。

已经上传到了 Github：

//github.com/javastacks/maven-demo-project

主要目录结构介绍：

所有目录创建完后，再根据文件性质把原系统所有除了（*.jar）文件移到对应的目录，这里没什么难度。

配置 Maven 环境信息：

<build>
	<filters>
		<filter>src/main/filters/filter-${env}.properties</filter>
	</filters>

	<resources>
		<resource>
			<directory>src/main/resources/config</directory>
			<filtering>true</filtering>
		</resource>
		<resource>
			<directory>src/main/resources/resource</directory>
			<filtering>false</filtering>
		</resource>
	</resources>
	
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-compiler-plugin</artifactId>
			<version>${maven-compiler-plugin.version}</version>
		</plugin>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-war-plugin</artifactId>
			<version>${maven-war-plugin.version}</version>
			<configuration>
				<failOnMissingWebXml>false</failOnMissingWebXml>
			</configuration>
		</plugin>
	</plugins>

</build>

<profiles>
	<profile>
		<id>dev</id>
		<activation>
			<activeByDefault>true</activeByDefault>
		</activation>
		<properties>
			<env>dev</env>
		</properties>
	</profile>
	<profile>
		<id>test</id>
		<properties>
			<env>test</env>
		</properties>
	</profile>
	<profile>
		<id>mirror</id>
		<properties>
			<env>mirror</env>
		</properties>
	</profile>
	<profile>
		<id>prod</id>
		<properties>
			<env>prod</env>
		</properties>
	</profile>
</profiles>

Maven 依赖转换

依赖转换就是要把所有原系统的（*.jar）依赖包全部转换为 Maven 依赖管理，这里是难点，要解决编译、启动、运行时遇到的 jar 包冲突、版本冲突等异常。

我的思路是先把一些核心框架的依赖进行转换，再进行一些比较独立的公共工具包的转换，最后就是一些不熟悉的依赖转换。

引入 Maven 依赖的时候，看下其所有附属的所有依赖，再逐渐从 lib 目录删除，直到全部删除完成即转换完成。

在找对应依赖的时候，如果中央仓库找不到，其他远程仓库能找到的，就在公司私库中添加该包所在的远程仓库代理配置。

如果中央仓库或者其他远程仓库都找不到的，比如第三方的 SDK 包，就上传到公司私库。怎么上传到私库，点击这里阅读，更多 Maven 教程在公众号Java技术栈回复maven进行阅读。

根据 JAR 包找 Maven 依赖的时候，可能有多个名称一样的依赖，不知道引用哪个，这时候需要去原始 JAR 包中看下包名，根据包名就大概知道坐标信息了。

依赖传递：

在依赖转换过程中，如果一个依赖又依赖了其他依赖，可以直接引用父依赖即可，如在老项目中存在：poi、poi-ooxm、poi-ooxml-schemas 这三个依赖：

但在 POI 依赖体系中，poi-ooxml 包又需要依赖其他两个包，所以只需要引入 poi-ooxml 依赖即可：

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
    <version>4.1.2</version>
</dependency>

这样就把这个包需要依赖的其他包都引进来了，这就是 Maven 管理依赖的好处，不会出现多包少包的情况，也能尽量避免依赖冲突。

依赖范围：

在老项目中，所有 jar 包都在 web-inf/lib 目录下，如：Servlet、JUnit，这些包在打完生产包之后也还在目录下，没有生命周期的管理。

在 Maven 中就能控制它们的生命周期：

<dependency>
	<groupId>javax.servlet</groupId>
	<artifactId>javax.servlet-api</artifactId>
	<version>${javax.servlet-api.version}</version>
	<scope>provided</scope>
</dependency>

<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>${junit.version}</version>
	<scope>test</scope>
</dependency>

Servlet 只需要编译时用到，JUnit 只需要测试时用到，控制好每个包的依赖范围，做到每个包的作用范围最小化。

解决冲突：

当传递的依赖版本不符合，或者是同一个包出现不同版本导致冲突的时候要学会使用排除：

或者强制指定包版本：

<dependency>
	<groupId>org.bouncycastle</groupId>
	<artifactId>bcprov-jdk16</artifactId>
	<version>${bctsp-jdk16.version}</version>
</dependency>

有的时候，还要根据需要使用 classifier 指定不同 JDK 的版本：

<dependency>
	<groupId>com.test</groupId>
	<artifactId>test</artifactId>
	<version>${test.version}</version>
	<classifier>JDK6</classifier>
</dependency>

如源代码编译报错，不知道引用的哪个 JAR 包、或者哪个版本，可以到原始项目中点对应的类引用进去看就知道了。

整个改造过程比较顺利，就是编译和运行时需要解决一些 JAR 包冲突导致的问题，根据上面的种种方法直至编译、启动正常。

以后可以舒舒服服用 Maven 咯。

整理了半天，无私分享给大家，希望你们能有收获，觉得不错，欢迎点赞、转发哟~

近期热文推荐：

1.Java 15 正式发布， 14 个新特性，刷新你的认知！！

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！

3.我用 Java 8 写了一段逻辑，同事直呼看不懂，你试试看。。

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！