Maven最佳实践：版本管理

企业开发 2018-05-11 07:35:24 阅读次数: 1

什么是版本管理

首先，这里说的版本管理（version management）不是指版本控制（version control），但是本文假设你拥有基本的版本控制的知识，了解subversion的基本用法。版本管理中说得版本是指构件（artifact）的版 本，而非源码的版本（如subversion中常见的rXXX，或者git中一次提交都有个sha1的commit号）。

比如我有一个项目，其artifactId为myapp，随着项目的进展，我们会生成这样一些jar：myapp-1.0- SNAPSHOT.jar，myapp-1.0.jar，myapp-1.1-SNAPSHOT.jar，myapp-1.0.1.jar等等。你可能会 说，这很简单啊，我在POM中改个version，mvn clean install不就完了？但这只是表面，本文我将讲述，snapshot和release版本的区别，如何自动化版本发布（如果你的项目有几十个 module，你就会觉得手工改POM来升级版本是很痛苦的事情），结合自动化发布的过程，这里还会介绍maven-release-plugin。此 外，一些scm概念也会被涉及到，比如tag和branch。

 

前提：版本控制

不管怎样，我们都需要建立一个项目并提交到SCM中，这里我以subversion为例。你得有一个配置好的subversion repository，这里我建立了一个空的svn仓库，其地址为：https://192.168.1.100:8443/svn/myapp/ 现在，该目录下只有三个空的典型的子目录：/trunk/, branches/, tags/。分别用来存放主干，分支，以及标签。

接着将项目导入到svn仓库中，到项目根目录，运行如下命令：

svn import -m 'project initialization' https://192.168.1.100:8443/svn/myapp/trunk 
（注意，这么做你会将目录下所有文件导入到svn库中，但是这其中某些目录和文件是不应该被导入的，如/target目录，以及eclipse相关的项目文件）

目前，我们将项目的版本设置为1.0-SNAPSHOT。

 

为什么用SNAPSHOT？

我先说说如果没有SNAPSHOT会是什么样子。假设你的项目有2个模块，A,B，其中A依赖B。这三个模块分别由甲，乙两个个人负责开发。在开发 过程中，因为A是依赖于B的，因此乙每次做一个改动都会影响到甲，于是，乙提交了一些更改后，需要让甲看到。这个时候，怎么做呢？乙对甲说，“你签出我的 代码，build一下就OK了”，甲有点不情愿，但还是照做了，签出代码，svn clean install，然后，发现build出错了，有个测试没有pass。甲郁闷了，对乙说，“你的代码根本不能用，我不想build，你build好了给 我”，乙看了看确实自己的代码build不过，于是回去解决了，然后打了个jar包，扔给甲，甲对了对groupId，artifactId，放到了自己 的.m2/repository/目录下，OK，能用了。

于是乙每次更新都这样做，打包，复制，然后甲粘贴，使用……渐渐的，大家发现这是个很笨的办法，这是纯手工劳动阿，程序员最BS的就是重复劳动。一 天，甲对乙说，“你知道nexus么？你把你的jar发布到nexus上就可以了，我要用就自动去下载，这多棒！”乙说“哦？有这好东西，我去看看”于是 乙发现了nexus这块新大陆，并成功的发布了B到nexus上。（见，Nexus入门指南，（图文） ）。

扫描二维码关注公众号，回复： 468516 查看本文章

但是，请注意，我们这里的一切都假设没有SNAPSHOT，因此如果乙不更改版本，甲下载一次如B-1.0.jar之后，maven认为它已经有了 正确的B的版本，就不会再重新下载。甲发现了这个问题，对乙说“你的更新我看不到，你更新了么？”乙说“不可能！我看看”，于是检查一下甲下载的C- 1.0.jar，发现那是几天前的。乙一拍脑袋，说“这简单，我更新一下我的版本就好了，我发布个B-1.1.jar上去，你更新下依赖版本”，甲照做 了，似乎这么做是可行的。

这里有一个问题，一次提交就更新一个版本，这明显不是正确的管理办法，此外，乙得不停的通知甲更新对B的依赖版本，累不累阿？1.0，或者说1.1，2.0，都代表了稳定，这样随随便便的改版本，能稳定么？

所以Maven有SNAPSHOT版本的概念，它与release版本对应，后者是指1.0，1.1，2.0这样稳定的发布版本。

现在乙可以将B的版本设置成1.0-SNAPSHOT，每次更改后，都mvn deploy到nexus中，每次deploy，maven都会将SNAPSHOT改成一个当前时间的timestamp，比如B-1.0- SNAPSHOT.jar到nexus中后，会成为这个样子：B-1.0-20081017-020325-13.jar。Maven在处理A中对于B的 SNAPSHOT依赖时，会根据这样的timestamp下载最新的jar，默认Maven每天 更新一次，如果你想让Maven强制更新，可以使用-U参数，如：mvn clean install -U 。

现在事情简化成了这个样子：乙做更改，然后mvn deploy，甲用最简单的maven命令就能得到最新的B。

 

从1.0-SNAPSHOT到1.0到1.1-SNAPSHOT

SNAPSHOT是快照的意思，项目到一个阶段后，就需要发布一个正式的版本（release版本）。一次正式的发布需要这样一些工作：

  1. 在trunk中，更新pom版本从1.0-SNAPSHOT到1.0
  2. 对1.0打一个svn tag
  3. 针对tag进行mvn deploy，发布正式版本
  4. 更新trunk从1.0到1.1-SNAPSHOT

你可以手工一步步的做这些事情，无非就是一些svn操作，一些pom编辑，还有一些mvn操作。但是你应该明白，手工做这些事情，一来繁琐，而来容易出错。因此这里我介绍使用maven插件来自动化这一系列动作。

SCM

首先我们需要在POM中加入scm信息，这样Maven才能够替你完成svn操作，这里我的配置如下：

Xml代码  
  1. <scm>  
  2.   <connection>scm:svn:http://192.168.1.100:8443/svn/myapp/trunk/</connection>  
  3.   <developerConnection>scm:svn:https://192.168.1.100:8443/svn/myapp/trunk/</developerConnection>  
  4. </scm>  

需要注意的是，很多windows使用的tortoiseSVN客户端，而没有svn命令行客户端，这会导致Maven所有svn相关的工作失败，因此，你首先确保svn --version能够运行。

分发仓库

想要让Maven帮我们自动发布，首先我们需要配置好分发仓库。关于这一点，见Maven最佳实践：Maven仓库——分发构件至远程仓库。

maven-release-plugin

紧接着，我们需要配置maven-release-plugin，这个插件会帮助我们升级pom版本，提交，打tag，然后再升级版本，再提交，等等。基本配置如下：

Xml代码  
  1. <plugin>  
  2.   <groupId>org.apache.maven.plugins</groupId>  
  3.   <artifactId>maven-release-plugin</artifactId>  
  4.   <version>2.0-beta-7</version>  
  5.   <configuration>  
  6.     <tagBase>https://192.168.1.100:8443/svn/myapp/tags/</tagBase>  
  7.   </configuration>  
  8. </plugin>  

GAV我就不多解释了，这里我们需要注意的是configuration元素下的tagBase元素，它代表了我们svn中的tag目录，也就是 说，maven-release-plugin帮我们打tag的时候，其基础目录是什么。这里，我填写了svn仓库中的标准的tags目录。

提交代码

接着，确保你的所有代码都提交了，如果你有未提交代码，release插件会报错，既然你要发布版本了，就表示代码是稳定的，所以要么要么把代码提交了，要么把本地的更改抛弃了。

开始工作

现在，屏住呼吸，执行：

mvn release:prepare

执行过程中，你会遇到这样的提示：

What is the release version for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) 1.0: :

——“你想将1.0-SNAPSHOT发布为什么版本？默认是1.0。”我要的就是1.0，直接回车。

What is SCM release tag or label for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) myapp-1.0: :

——“发布的tag标签名称是什么？默认为myapp-1.0。”我还是要默认值，直接回车。

What is the new development version for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) 1.1-SNAPSHOT: :

——“主干上新的版本是什么？默认为1.1-SNAPSHOT。”哈，release插件会自动帮我更新版本到1.1-SNAPSHOT，很好，直接回车。

然后屏幕刷阿刷，maven在build我们的项目，并进行了一些svn操作，你可以仔细查看下日志。

那么结果是什么呢？你可以浏览下svn仓库：

  • 我们多了一个tag：https://192.168.1.100:8443/svn/myapp/tags/myapp-1.0/，这就是需要发布的版本1.0。
  • 再看看trunk中的POM，其版本自动升级成了1.1-SNAPSHOT。

这不正是我们想要的么？等等，好像缺了点什么，对了，1.0还没有发布到仓库中呢。

再一次屏住呼吸，执行：

mvn release:perform

maven-release-plugin会自动帮我们签出刚才打的tag，然后打包，分发到远程Maven仓库中，至此，整个版本的升级，打标签，发布等工作全部完成。我们可以在远程Maven仓库中看到正式发布的1.0版本。

这可是自动化的 ，正式的 版本发布！

 

Maven的版本规则

前面我们提到了SNAPSHOT和Release版本的区别，现在看一下，为什么要有1.0，1.1，1.1.1这样的版本，这里的规则是什么。

Maven主要是这样定义版本规则的：

<主版本>.<次版本>.<增量版本>

比如说1.2.3，主版本是1，次版本是2，增量版本是3。

主版本一般来说代表了项目的重大的架构变更，比如说Maven 1和Maven 2，在架构上已经两样了，将来的Maven 3和Maven 2也会有很大的变化。次版本一般代表了一些功能的增加或变化，但没有架构的变化，比如说Nexus 1.3较之于Nexus 1.2来说，增加了一系列新的或者改进的功能（仓库镜像支持，改进的仓库管理界面等等），但从大的架构上来说，1.3和1.2没什么区别。至于增量版本， 一般是一些小的bug fix，不会有重大的功能变化。

一般来说，在我们发布一次重要的版本之后，随之会开发新的版本，比如说，myapp-1.1发布之后，就着手开发myapp-1.2了。由于 myapp-1.2有新的主要功能的添加和变化，在发布测试前，它会变得不稳定，而myapp-1.1是一个比较稳定的版本，现在的问题是，我们在 myapp-1.1中发现了一些bug（当然在1.2中也存在），为了能够在段时间内修复bug并仍然发布稳定的版本，我们就会用到分支 （branch），我们基于1.1开启一个分支1.1.1，在这个分支中修复bug，并快速发布。这既保证了版本的稳定，也能够使bug得到快速修复，也 不同停止1.2的开发。只是，每次修复分支1.1.1中的bug后，需要merge代码到1.2（主干）中。

上面讲的就是我们为什么要用增量版本。

 

实战分支

目前我们trunk的版本是1.1-SNAPSHOT，其实按照前面解释的版本规则，应该是1.1.0-SNAPSHOT。

现在我们想要发布1.1.0，然后将主干升级为1.2.0-SNAPSHOT，同时开启一个1.1.x的分支，用来修复1.1.0中的bug。

首先，在发布1.1.0之前，我们创建1.1.x分支，运行如下命令：

mvn release:branch -DbranchName=1.1.x -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false

这是maven-release-plugin的branch目标，我们指定branch的名称为1.1.x，表示这里会有版本1.1.1, 1.1.2等等。updateBranchVersions=true的意思是在分支中更新版本，而 updateWorkingCopyVersions=false是指不更改当前工作目录（这里是trunk）的版本。

在运行该命令后，我们会遇到这样的提示：

What is the branch version for "Unnamed - org.myorg:myapp:jar:1.1-SNAPSHOT"? (org.myorg:myapp) 1.1-SNAPSHOT: :

——"分支中的版本号是多少？默认为1.1-SNAPSHOT" 这时我们想要的版本是1.1.1-SNAPSHOT，因此输入1.1.1-SNAPSHOT，回车，maven继续执行直至结束。

接着，我们浏览svn仓库，会看到这样的目录：https://192.168.1.100:8443/svn/myapp/branches/1.1.x/，打开其中的POM文件，其版本已经是1.1.1-SNAPSHOT。

分支创建好了，就可以使用release:prepare和release:perform为1.1.0打标签，升级trunk至1.2.0-SNAPSHOT，然后分发1.1.0。

至此，一切OK。

 

小结

本文讲述了如何使用Maven结合svn进行版本管理。解释了Maven中SNAPSHOT版本的来由，以及Maven管理版本的规则。并结合 SCM的tag和branch概念展示了如何使用maven-release-plugin发布版本，以及创建分支。本文涉及的内容比较多，且略显复杂， 不过掌握版本管理的技巧对于项目的正规化管理来说十分重要。Maven为我们提供了一些一套比较成熟的机制，值得掌握。

所有用Maven管理的真实的项目都应该是分模块的，每个模块都对应着一个pom.xml。它们之间通过继承和聚合（也称作多模块，multi- module）相互关联。那么，为什么要这么做呢？我们明明在开发一个项目，划分模块后，导入Eclipse变成了N个项目，这会带来复杂度，给开发带来 不便。

 

为了解释原因，假设有这样一个项目，很常见的Java Web应用。在这个应用中，我们分了几层：

  • Dao层负责数据库交互，封装了Hibernate交互的类。
  • Service层处理业务逻辑，放一些Service接口和实现相关的Bean。
  • Web层负责与客户端交互，主要有一些Structs的Action类。

对应的，在一个项目中，我们会看到一些包名：

  • org.myorg.app.dao
  • org.myorg.app.service
  • org.myorg.app.web
  • org.myorg.app.util

这样整个项目的框架就清晰了，但随着项目的进行，你可能会遇到如下问题：

  1. 这个应用可能需要有一个前台和一个后台管理端（web或者swing），你发现大部分dao，一些service，和大部分util是在两个应用中可。这样的问题，你一周内遇到了好几次。
  2. pom.xml中的依赖列表越来越长以重用的，但是，由于目前只有一个项目（WAR），你不得不新建一个项目依赖这个WAR，这变得非常的恶心， 因为在Maven中配置对WAR的依赖远不如依赖JAR那样简单明了，而且你根本不需要org.myorg.app.web。有人修改了dao，提交到 svn并且不小心导致build失败了，你在编写service的代码，发现编译不过，只能等那人把dao修复了，你才能继续进行，很多人都在修改，到后 来你根本就不清楚哪个依赖是谁需要的，渐渐的，很多不必要的依赖被引入。甚至出现了一个依赖有多个版本存在。
  3. build整个项目的时间越来越长，尽管你只是一直在web层工作，但你不得不build整个项目。
  4. 某个模块，比如util，你只想让一些经验丰富的人来维护，可是，现在这种情况，每个开发者都能修改，这导致关键模块的代码质量不能达到你的要求。

我们会发现，其实这里实际上没有遵守一个设计模式原则：“高内聚，低耦合”。虽然我们通过包名划分了层次，并且你还会说，这些包的依赖都是单向的，没有包的环依赖。这很好，但还不够，因为就构建层次来说，所有东西都被耦合在一起了。因此我们需要使用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)   

 

上述简单示意图中，有一个父项目(app-parent)聚合很多子项目（app-util, app-dao, app-service, app-web）。每个项目，不管是父子，都含有一个pom.xml文件。而且要注意的是，小括号中标出了每个项目的打包类型。父项目是pom,也只能是 pom。子项目有jar，或者war。根据它包含的内容具体考虑。

 

这些模块的依赖关系如下：

 

app-dao      --> app-util

app-service --> app-dao

app-web     --> app-service

 

注意依赖的传递性（大部分情况是传递的，除非你配置了特殊的依赖scope），app-dao依赖于app-util，app-service依赖 于app-dao，于是app-service也依赖于app-util。同理，app-web依赖于app-dao,app-util。

 

用项目层次的划分替代包层次的划分能给我们带来如下好处：

  1. 方便重用，如果你有一个新的swing项目需要用到app-dao和app-service，添加对它们的依赖即可，你不再需要去依赖一个WAR。而有些模块，如app-util，完全可以渐渐进化成公司的一份基础工具类库，供所有项目使用。这是模块化最重要的一个目的。
  2. 由于你现在划分了模块，每个模块的配置都在各自的pom.xml里，不用再到一个混乱的纷繁复杂的总的POM中寻找自己的配置。
  3. 如果你只是在app-dao上工作，你不再需要build整个项目，只要在app-dao目录运行mvn命令进行build即可，这样可以节省时间，尤其是当项目越来越复杂，build越来越耗时后。
  4. 某些模块，如app-util被所有人依赖，但你不想给所有人修改，现在你完全可以从这个项目结构出来，做成另外一个项目，svn只给特定的人访问，但仍提供jar给别人使用。
  5. 多模块的Maven项目结构支持一些Maven的更有趣的特性（如DepencencyManagement），这留作以后讨论。

接下来讨论一下POM配置细节，实际上非常简单，先看app-parent的pom.xml：

Xml代码  
  1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
  3.     <modelVersion>4.0.0</modelVersion>  
  4.     <groupId>org.myorg.myapp</groupId>  
  5.     <artifactId>app-parent</artifactId>  
  6.     <packaging>pom</packaging>  
  7.     <version>1.0-SNAPSHOT</version>  
  8.     <modules>  
  9.         <module>app-util</module>  
  10.         <module>app-dao</module>  
  11.         <module>app-service</module>  
  12.         <module>app-web</module>  
  13.     </modules>  
  14. </project>  

Maven的坐标GAV（groupId, artifactId, version）在这里进行配置，这些都是必须的。特殊的地方在于，这里的packaging为pom。所有带有子模块的项目的packaging都为 pom。packaging如果不进行配置，它的默认值是jar，代表Maven会将项目打成一个jar包。

该配置重要的地方在于modules，例子中包含的子模块有app-util, app-dao, app-service, app-war。在Maven build app-parent的时候，它会根据子模块的相互依赖关系整理一个build顺序，然后依次build。

这就是一个父模块大概需要的配置，接下来看一下子模块符合配置继承父模块。、

Xml代码  
  1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
  3.     <parent>  
  4.         <artifactId>app-parent</artifactId>  
  5.         <groupId>org.myorg.myapp</groupId>  
  6.         <version>1.0-SNAPSHOT</version>  
  7.     </parent>  
  8.     <modelVersion>4.0.0</modelVersion>  
  9.     <artifactId>app-util</artifactId>  
  10.     <dependencies>  
  11.         <dependency>  
  12.             <groupId>commons-lang</groupId>  
  13.             <artifactId>commons-lang</artifactId>  
  14.             <version>2.4</version>  
  15.         </dependency>  
  16.     </dependencies>  
  17. </project>  

app-util模块继承了app-parent父模块，因此这个POM的一开始就声明了对app-parent的引用，该引用是通过Maven坐 标GAV实现的。而关于项目app-util本身，它却没有声明完整GAV，这里我们只看到了artifactId。这个POM并没有错，groupId 和version默认从父模块继承了。实际上子模块从父模块继承一切东西，包括依赖，插件配置等等。

此外app-util配置了一个对于commons-lang的简单依赖，这是最简单的依赖配置形式。大部分情况，也是通过GAV引用的。

再看一下app-dao，它也是继承于app-parent，同时依赖于app-util：

Xml代码  
  1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
  3.     <parent>  
  4.         <artifactId>app-parent</artifactId>  
  5.         <groupId>org.myorg.myapp</groupId>  
  6.         <version>1.0-SNAPSHOT</version>  
  7.     </parent>  
  8.     <modelVersion>4.0.0</modelVersion>  
  9.     <artifactId>app-dao</artifactId>  
  10.     <dependencies>  
  11.         <dependency>  
  12.             <groupId>org.myorg.myapp</groupId>  
  13.             <artifactId>app-util</artifactId>  
  14.             <version>${project.version}</version>  
  15.         </dependency>  
  16.     </dependencies>  
  17. </project>  

该配置和app-util的配置几乎没什么差别，不同的地方在于，依赖变化了，app-dao依赖于app-util。这里要注意的是 version的值为${project.version}，这个值是一个属性引用，指向了POM的project/version的值，也就是这个 POM对应的version。由于app-dao的version继承于app-parent，因此它的值就是1.0-SNAPSHOT。而app- util也继承了这个值，因此在所有这些项目中，我们做到了保持版本一致。

这里还需要注意的是，app-dao依赖于app-util，而app-util又依赖于commons-lang，根据传递性，app-dao也拥有了对于commons-lang的依赖。

app-service我们跳过不谈，它依赖于app-dao。我们最后看一下app-web：

Xml代码  
  1. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
  2.     xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">  
  3.     <parent>  
  4.         <artifactId>app-parent</artifactId>  
  5.         <groupId>org.myorg.myapp</groupId>  
  6.         <version>1.0-SNAPSHOT</version>  
  7.     </parent>  
  8.     <modelVersion>4.0.0</modelVersion>  
  9.     <artifactId>app-web</artifactId>  
  10.     <packaging>war</packaging>  
  11.     <dependencies>  
  12.         <dependency>  
  13.             <groupId>org.myorg.myapp</groupId>  
  14.             <artifactId>app-service</artifactId>  
  15.             <version>${project.version}</version>  
  16.         </dependency>  
  17.     </dependencies>  
  18. </project>  

app-web依赖于app-service，因此配置了对其的依赖。

由于app-web是我们最终要部署的应用，因此它的packaging是war。为此，你需要有一个目录src/main/webapp。并在这 个目录下拥有web应用需要的文件，如/WEB-INF/web.xml。没有web.xml，Maven会报告build失败，此外你可能还会有这样一 些子目录：/js, /img, /css ... 。

 

看看Maven是如何build整个项目的，我们在 app-parent 根目录中运行 mvn clean install ，输出的末尾会有大致这样的内容：

 

...

...

[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[app-web] in [/home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in[50 msecs]
[INFO] Building war: /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war
[INFO] [install:install]
[INFO] Installing /home/juven/workspaces/ws-others/myapp/app-web/target/app-web-1.0-SNAPSHOT.war to /home/juven/.m2/repository/org/myorg/myapp/app-web/1.0-SNAPSHOT/app-web-1.0-SNAPSHOT.war
[INFO] 
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] app-parent ............................................ SUCCESS [1.191s]
[INFO] app-util .............................................. SUCCESS [1.274s]
[INFO] app-dao ............................................... SUCCESS [0.583s]
[INFO] app-service ........................................... SUCCESS [0.593s]
[INFO] app-web ............................................... SUCCESS [0.976s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Sat Dec 27 08:20:18 PST 2008
[INFO] Final Memory: 3M/17M
[INFO] ------------------------------------------------------------------------

 

注意Reactor Summary，整个项目根据我们希望的顺序进行build。Maven根据我们的依赖配置，智能的安排了顺序，app-util, app-dao, app-service, app-web。

 

最后，你可以在 app-web/target 目录下找到文件 app-web-1.0-SNAPSHOT.war ，打开这个war包，在 /WEB-INF/lib 目录看到了 commons-lang-2.4.jar，以及对应的app-util, app-dao, app-service 的jar包。Maven自动帮你处理了打包的事情，并且根据你的依赖配置帮你引入了相应的jar文件。

 

使用多模块的Maven配置，可以帮助项目划分模块，鼓励重用，防止POM变得过于庞大，方便某个模块的构建，而不用每次都构建整个项目，并且使得针对某个模块的特殊控制更为方便。本文同时给出了一个实际的配置样例，展示了如何使用Maven配置多模块项目。

猜你喜欢

转载自shuzheng5201314.iteye.com/blog/2262143
今日推荐
基于大语言模型的开源知识库问答系统 MaxKB GitHub Star 数量突破 5,000 个！
美国拟限制 AI 大模型出口中国和俄罗斯
苹果将与 OpenAI 达成协议，将 ChatGPT 应用于 iPhone
openKylin 社区生态委员会第六次会议圆满召开
阿里云正式发布通义千问 2.5
Python 3.13 发布首个 Beta：实验性自由线程模式和 JIT、改进交互式解释器
Stack Overflow 拿我的代码去训练 AI 大模型，还封了我的账号
Pop!_OS 的 COSMIC 桌面完成 App Store 上架工作
《2024 年一季度互联网投融资运行情况》研究报告
报告：Django 仍然是 74% 开发者的首选
15 年前上了“FFmpeg 耻辱柱”，今天他还得谢谢咱——腾讯QQPlayer一雪前耻？
TIOBE 5 月榜单：Fortran “复活”进入 Top 10
周排行
记一下去大梅沙的准备（2018-05-26）
Spring 注解 事务
基于HTTP协议的客户端缓存
阿里云rds 备份和还原
[PHP] 几个拖慢 PHP 程序/API 运行速度的点
python 代码风格------------PEP8规则
js控制json生成菜单——自制菜单（一）
将字符串: 'k:1|k1:2|k2:3|k3:4 ' ,处理成 python 字典: {'k':1, 'k1':2, ...}
微信小程序转支付宝小程序
Qt551.窗口滚动条
每日归档
更多
2024-05-13(18)
2024-05-12(0)
2024-05-11(38)
2024-05-10(38)
2024-05-09(35)
2024-05-08(42)
2024-05-07(14)
2024-05-06(40)
2024-05-05(0)
2024-05-04(7)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022