标签：ble 判断 测试 代码 文件的 ted abc maven仓库 动作
问题：
之前一直用的是mvn install 命令来构建项目，但是最近发现最新的代码没有在war包中。之前看的说 mvn install 命令会执行之前的所有阶段，会被编译，测试，打包。
经查最后采用mvn clean package -DskipTests=true -P prod (先清除，再打包，跳过测试，选择prod生产环境的配置文件构建)
原因：
maven构建过程
mvn clean ----- 【清理】 将编译（mvn compile）产生的【target】文件夹删除掉，但是不会删除本地的maven仓库已经生成的jar文件。
mvn compile --- 【编译】在项目根目录生【target】目录，里面包含【classes】文件夹，里面是已经编译好的java类（.class文件）
mvn test-------- 【测试】会先生成target文件夹，里面有【classes】和【test-classes】文件夹，所 以执行mvn test命令时，会先编译项目，在执行测试代码
mvn package----【打包】看到项目的根目录下【编译】后生成的【target】文件夹中多了一个Hello-0.0.1-SNAPSHOT.jar，这个Hello-0.0.1-SNAPSHOT.jar就是打包成功之后Maven帮我们生成的jar文件，package命令会先执行编译再执行打包
mvn install -----就是把maven构建项目的【清理clean】→【编译】→【测试】→【打包】的这几个过程都做了，同时将打包好的jar包发布到本地的Maven仓库中，所以maven最常用的命令还是"mvn install"，这个命令能做的事情最多，所以这个最常用
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 文件中设置，类似如下：
<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"> ... <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
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不进行新包的生成直接返回。
protected void execute() throws ArchiverException, IOException { if ( ! checkForced() ) { return; } if ( doubleFilePass ) { skipWriting = true; createArchiveMain(); skipWriting = false; createArchiveMain(); } else { createArchiveMain(); } finalizeZipOutputStream( zOut ); }
所以除了那个强制的参数以外，就是看什么时候 isUptodate 为true，查看关键代码：
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 参数
jar-plugin源代码地址：http://svn.apache.org/repos/asf/maven/plugins/tags/maven-jar-plugin-2.4
参考：https://blog.csdn.net/abc86319253/article/details/44019881
标签：ble 判断 测试 代码 文件的 ted abc maven仓库 动作
原文地址：https://www.cnblogs.com/gcgc/p/10475245.html
