有时候用mvn install后，新改的内容不生效，一定要后来使用mvn clean install 才生效，由于之前没有做记录，以及记不清是什么情况下才会出现的问题，于是想看看clean和不clean的区别。
就如大家知道的，maven在执行一个生命周期的命令的是时候将会执行之前的所有生命周期操作，比如执行mvn install，会执行前面一系列的动作包括 compile ,package , test 等，具体请查看maven的官方文档。这个特性使maven的命令更加简洁易用。
再来分析原来的问题，为什么修改的内容不生效，肯定是最终打出来的war包中的内容没有更新，而war包中会依赖其他子工程的jar包，如果jar 包没有更新过，那war包调用老的jar包也会导致新内容不生效。定位到问题的原因应该是jar包没有用最新的资源（java或者配置文件），那jar包 又是什么时候，谁去打的呢。
上面我们提到我们执行mvn install的时候会先执行mvn package，maven就是通过这个生命周期来根据用户配置，进行打包（war、jar或者其他），这会在每个工程 pom.xml 文件中设置，类似如下：
|
1
2
3
4
5
6
7
8
9
10
|
<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.0http://maven.apache.org/xsd/maven-4.0.0.xsd"> ... <packaging>war</packaging> ...</project> |
这里指定package的时候打成一个war包，改成jar，就会被打成jar包。
我们看jar形式的情况，mvn package 会调用 maven-jar-plugin 这个插件进行打包。
下面我们做一些实验来看这个插件打包的时候的情况
1. 修改target目录下打好的jar包中class以及配置文件的内容，在运行命令mvn package，结果target包中的内容没有被覆盖。
2. 修改源代码中的内容，再运行命令mvn package,结果target包中的内容被覆盖了，产生了新的包。
3. 修改target目录下打好的jar包中的内容，运行命令mvn package -Djar.forceCreation，这个参数应该是强制创建jar包，所以结果target中的jar包内容被覆盖了，产生了新的jar包。
根据上面的实验好像还是不能解释什么时候应该用clean将target下面的内容删除重新生成，jar包，不过至少是明白了一些规则。
下面我们还是去看看maven-jar-plugin的源码吧。
之前，我提一点，maven的debugg信息非常完备，需要查看debug信息只要在命令后面添加 -X 参数即可，如：
mvn clean package -X就能看到非常丰富的DEBUG信息。
回来，我们发现org.codehaus.plexus.archiver.AbstractArchiver中的关键一段，用来判断是否强制新建jar
|
1
2
3
4
5
6
7
8
9
10
|
protected boolean checkForced() throws ArchiverException { if ( !isForced() && isSupportingForced() && isUptodate() ) { getLogger().debug( "Archive " + getDestFile() + " is uptodate." ); return false; } return true; } |
这个方法是校验是否强制重新创建jar包，只有当
1. 没有将 jar.forceCreation 参数设为true
2. 并且支持强制设置
3. up to date,意思就是被认为是最新的内容，没有改动
这个时候maven不进行新包的生成直接返回。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
protected void execute() throws ArchiverException, IOException { if ( ! checkForced() ) { return; } if ( doubleFilePass ) { skipWriting = true; createArchiveMain(); skipWriting = false; createArchiveMain(); } else { createArchiveMain(); } finalizeZipOutputStream( zOut ); } |
所以除了那个强制的参数以外，就是看什么时候 isUptodate 为true，查看关键代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
protected boolean isUptodate() throws ArchiverException { final File zipFile = getDestFile(); final long destTimestamp = zipFile.lastModified(); if ( destTimestamp == 0 ) { getLogger().debug( "isUp2date: false (Destination " + zipFile.getPath() + " not found.)" ); return false; // File doesn't yet exist } final Iterator it = resources.iterator(); if ( !it.hasNext() ) { getLogger().debug( "isUp2date: false (No input files.)" ); return false; // No timestamp to compare } while ( it.hasNext() ) { final Object o = it.next(); final long l; if ( o instanceof ArchiveEntry ) { l = ( (ArchiveEntry) o ).getResource() .getLastModified(); } else if ( o instanceof PlexusIoResourceCollection ) { try { l = ( (PlexusIoResourceCollection) o ).getLastModified(); } catch ( final IOException e ) { throw new ArchiverException( e.getMessage(), e ); } } else { throw new IllegalStateException( "Invalid object type: " + o.getClass() .getName() ); } if ( l == PlexusIoResource.UNKNOWN_MODIFICATION_DATE ) { // Don't know what to do. Safe thing is to assume not up2date. getLogger().debug( "isUp2date: false (Resource with unknown modification date found.)" ); return false; } if ( l > destTimestamp ) { getLogger().debug( "isUp2date: false (Resource with newer modification date found.)" ); return false; } } getLogger().debug( "isUp2date: true" ); return true; } |
代码中提到有这么几个情况，会认为jar包不是最新的：
1. jar包不存在（其实就是mvn clean的效果）
2. 传入比较的文件资源不存在
3. Resource with unknown modification date found，资源的修改时间未知
4. Resource with newer modification date found，jar包的最后修改时间比资源的最后修改时间早
总结
1. 理论上来讲不做mvn clean 得到的jar包应该是最新的，除非其他方式修改jar包中的内容而不修改源代码。
2. 平时可以用mvn install，而不进行chean节省时间（如果你觉得节省时间多的话），但最保险还是用 mvn clean install 生成最新的jar包或其他包
3. 不想用mvn clean又想保证jar包最新，建议添加-Djar.forceCreation参数
4. 由maven的生命周期可知,当使用deploy时同样会有clean与不用clean的区别, 因此为了保险起见,建议package,install,deploy前均先clean
jar-plugin源代码地址：http://svn.apache.org/repos/asf/maven/plugins/tags/maven-jar-plugin-2.4
到此这篇关于maven 在执行package,install,deploy时使用clean与不使用clean的区别的文章就介绍到这了,更多相关maven 执行package,install,deploy内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://www.cnblogs.com/kexianting/p/11459671.html
