在軟件開發過程中，程序員會通過重構等方式不斷地優化自己的代碼，使其變得更簡潔、更靈活。同理，程序員也應該能夠對Maven項目的依賴瞭然於胸，並對其進行優化，如去除多餘的依賴，顯式地聲明某些必要的依賴。
通過閱讀本章前面的內容，讀者應該能夠瞭解到：Maven會自動解析所有項目的直接依賴和傳遞性依賴，並且根據規則正確判斷每個依賴的範圍，對於一些依賴衝突，也能進行調節，以確保任何一個構件只有唯一的版本在依賴中存在。在這些工作之後，最後得到的那些依賴被稱為已解析依賴（Resolved Dependency）。可以運行如下的命令查看當前項目的已解析依賴：
在account-email項目中執行該命令，結果如圖5-5所示。
圖5-5 已解析依賴列表
圖5-5顯示了所有account-email的已解析依賴，同時，每個依賴的範圍也得以明確標示。
在此基礎上，還能進一步瞭解已解析依賴的信息。將直接在當前項目POM聲明的依賴定義為頂層依賴，而這些頂層依賴的依賴則定義為第二層依賴，以此類推，有第三、第四層依賴。當這些依賴經Maven解析後，就會構成一個依賴樹，通過這棵依賴樹就能很清楚地看到某個依賴是通過哪條傳遞路徑引入的。可以運行如下命令查看當前項目的依賴樹：
在acccount-email中執行該命令，效果如圖5-6所示。
圖5-6 已解析依賴樹
從圖5-6中能夠看到，雖然我們沒有聲明org.slf4j：slf4j-api：1.3這一依賴，但它還是經過com.icegreen：greenmail：1.3成為了當前項目的傳遞性依賴，而且其範圍是test。
使用dependency：list和dependency：tree可以幫助我們詳細瞭解項目中所有依賴的具體信息，在此基礎上，還有dependency：analyze工具可以幫助分析當前項目的依賴。
為了說明該工具的用途，先將5.3.1節中的spring-context這一依賴刪除，然後構建項目，你會發現編譯、測試和打包都不會有任何問題。通過分析依賴樹，可以看到spring-context是spring-context-support的依賴，因此會得以傳遞到項目的classspath中。現在再運行如下命令：
結果如圖5-7所示。
圖5-7 使用但未聲明的依賴與聲明但未使用的依賴
該結果中重要的是兩個部分。首先是Used undeclared dependencies，意指項目中使用到的，但是沒有顯式聲明的依賴，這裡是spring-context。這種依賴意味著潛在的風險，當前項目直接在使用它們，例如有很多相關的Java import聲明，而這種依賴是通過直接依賴傳遞進來的，當升級直接依賴的時候，相關傳遞性依賴的版本也可能發生變化，這種變化不易察覺，但是有可能導致當前項目出錯。例如由於接口的改變，當前項目中的相關代碼無法編譯。這種隱藏的、潛在的威脅一旦出現，就往往需要耗費大量的時間來查明真相。因此，顯式聲明任何項目中直接用到的依賴。
結果中還有一個重要的部分是Unused declared dependencies，意指項目中未使用的，但顯式聲明的依賴，這裡有spring-core和spring-beans。需要注意的是，對於這樣一類依賴，我們不應該簡單地直接刪除其聲明，而是應該仔細分析。由於dependency：analyze只會分析編譯主代碼和測試代碼需要用到的依賴，一些執行測試和運行時需要的依賴它就發現不了。很顯然，該例中的spring-core和spring-beans是運行Spring Framework項目必要的類庫，因此不應該刪除依賴聲明。當然，有時候確實能通過該信息找到一些沒用的依賴，但一定要小心測試。