maven依賴問題，總是去伺服器擷取舊的依賴，而不擷取本地的

Maven中建立的依賴管理方式基本已成為Java語言依賴管理的事實标準，Maven的替代者Gradle也基本沿用了Maven的依賴管理機制。在Maven依賴管理中，唯一辨別一個依賴項是由該依賴項的三個屬性構成的，分别是groupId、artifactId以及version。這三個屬性可以唯一确定一個元件（Jar包或者War包）。

其實在Nexus倉庫中，一個倉庫一般分為public(Release)倉和SNAPSHOT倉，前者存放正式版本，後者存放快照版本。如果在項目配置檔案中（無論是build.gradle還是pom.xml）指定的版本号帶有’-SNAPSHOT’字尾，比如版本号為’Junit-4.10-SNAPSHOT’，那麼打出的包就是一個快照版本。

快照版本和正式版本的主要差別在于，本地擷取這些依賴的機制有所不同。假設你依賴一個庫的正式版本，建構的時候建構工具會先在本次倉庫中查找是否已經有了這個依賴庫，如果沒有的話才會去遠端倉庫中去拉取。是以假設你釋出了Junit-4.10.jar到了遠端倉庫，有一個項目依賴了這個庫，它第一次建構的時候會把該庫從遠端倉庫中下載下傳到本地倉庫緩存，以後再次建構都不會去通路遠端倉庫了。是以如果你修改了代碼，向遠端倉庫中釋出了新的軟體包，但仍然叫Junit-4.10.jar，那麼依賴這個庫的項目就無法得到最新更新。你隻有在重新釋出的時候更新版本，比如叫做Junit-4.11.jar，然後通知依賴該庫的項目組也修改依賴版本為Junit-4.11,這樣才能使用到你最新添加的功能。

這種方式在團隊内部開發的時候會變的特别蛋痛。假設有兩個小組負責維護兩個元件，example-service和example-ui,其中example-ui項目依賴于example-service。而這兩個項目每天都會建構多次，如果每次建構你都要更新example-service的版本，那麼你會瘋掉。這個時候SNAPSHOT版本就派上用場了。每天日常建構時你可以建構example-service的快照版本，比如example-service-1.0-SNAPSHOT.jar，而example-ui依賴該快照版本。每次example-ui建構時，會優先去遠端倉庫中檢視是否有最新的example-service-1.0-SNAPSHOT.jar，如果有則下載下傳下來使用。即使本地倉庫中已經有了example-service-1.0-SNAPSHOT.jar，它也會嘗試去遠端倉庫中檢視同名的jar是否是最新的。有的人可能會問，這樣不就不能充分利用本地倉庫的緩存機制了嗎？别着急，Maven比我們想象中的要聰明。在配置Maven的Repository的時候中有個配置項，可以配置對于SNAPSHOT版本向遠端倉庫中查找的頻率。頻率共有四種，分别是always、daily、interval、never。當本地倉庫中存在需要的依賴項目時，always是每次都去遠端倉庫檢視是否有更新，daily是隻在第一次的時候檢視是否有更新，當天的其它時候則不會檢視；interval允許設定一個分鐘為機關的間隔時間，在這個間隔時間内隻會去遠端倉庫中查找一次，never是不會去遠端倉庫中查找（這種就和正式版本的行為一樣了）。

Maven版本的配置方式為：

<repository>
    <id>myRepository</id>
    <url>...</url>
    <snapshots>
        <enabled>true</enabled>
        <updatePolicy>XXX</updatePolicy>
    </snapshots>
</repository>
           

其中updatePolicy就是那4種類型之一。如果配置間隔時間更新，可以寫作interval:XX(XX是間隔分鐘數)。daily配置是預設值。

而在Gradle，可以設定本地緩存的更新政策。

configurations.all {

// check for updates every build
resolutionStrategy.cacheChangingModulesFor  0,'seconds'

}
           

當然也可以按照分鐘或者小時來設定.

configurations.all {

resolutionStrategy.cacheChangingModulesFor  10, ‘minutes'

}

configurations.all {

resolutionStrategy.cacheChangingModulesFor  4, ‘hours'

}
           

是以一般在開發模式下，我們可以頻繁的釋出SNAPSHOT版本，以便讓其它項目能實時的使用到最新的功能做聯調；當版本趨于穩定時，再釋出一個正式版本，供正式使用。當然在做正式釋出時，也要確定目前項目的依賴項中不包含對任何SNAPSHOT版本的依賴，保證正式版本的穩定性。

轉載自：https://www.cnblogs.com/huang0925/p/5169624.html