mvn 打包帶clean和不帶clean區別
一.簡介
之前寫程式碼的過程中曾經遇到過問題,用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 檔案中設定,類似如下:
<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 這個外掛進行打包。 下面我們做一些實驗來看這個外掛打包的時候的情況
- 修改target目錄下打好的jar包中class以及配置檔案的內容,在執行命令mvn package,結果target包中的內容沒有被覆蓋。
- 修改原始碼中的內容,再執行命令mvn package,結果target包中的內容被覆蓋了,產生了新的包。
- 修改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包,只有當
- 沒有將 jar.forceCreation 引數設為true
- 並且支援強制設定
- 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包不是最新的:
- jar包不存在(其實就是mvn clean的效果)
- 傳入比較的檔案資源不存在
- Resource with unknown modification date found,資源的修改時間未知
- Resource with newer modification date found,jar包的最後修改時間比資源的最後修改時間早
總結
- 理論上來講不做mvn clean 得到的jar包應該是最新的,除非其他方式修改jar包中的內容而不修改原始碼。
- 平時可以用mvn install,而不進行chean節省時間(如果你覺得節省時間多的話),但最保險還是用 mvn clean install 生成最新的jar包或其他包
- 不想用mvn clean又想保證jar包最新,建議新增 -Djar.forceCreation 引數
jar-plugin原始碼地址:http://svn.apache.org/repos/asf/maven/plugins/tags/maven-jar-plugin-2.4
本文版權歸作者所有,歡迎轉載,請務必新增原文連結。