maven依賴編譯

1. 解決 maven 項目無法編譯的問題

在使用 Idea 編譯 maven 項目時，若遇到錯誤提示，應檢查依賴的 jar 包是否完整下載。

錯誤提示可能顯示為 '無法找到或載入主類' 或者其他與 jar 包缺失相關的信息。

問題通常源於本地 Maven 倉庫中 jar 包下載不完全。解決步驟如下：首先，刪除本地倉庫中存在問題的 jar 包；其次，重新打包項目。

實現這一操作，可以編寫 Java 類利用 commons-io 包。具體步驟包括識別問題 jar 包路徑，調用 commons-io 方法進行刪除，最後通過 Idea 的 'reload' 功能更新項目依賴。

編寫步驟如下：

1. 創建 Java 類，導入 commons-io 相關包。

2. 編寫方法，通過 Maven 倉庫路徑和 jar 包名識別問題 jar 包。

3. 使用 commons-io 方法刪除識別出的 jar 包。

4. 在 Idea 中執行 'reload'，更新項目依賴。

執行上述步驟後，問題 jar 包應被正確刪除，項目重新編譯時不應再出現依賴問題。

2. 純干貨！華為軟體開發雲編譯構建之Maven

華為軟體開發雲中的Maven編譯構建是一個基於Maven項目管理和整合工具的自動化構建過程。以下是關於華為軟體開發雲編譯構建之Maven的詳細解答：

1. Maven的基本功能與優勢： 功能：Maven是一個項目管理和整合工具，提供構建生命周期框架，幫助開發者自動完成基礎構建配置，包括管理構建、文檔、報告、依賴、版本控制、發布、分發等。 優勢：標准化、自動化、高效性，以及強大的可擴展性。通過Maven插件，還能實現代碼檢查、單元測試覆蓋率統計和持續集成等功能。

2. 華為軟體開發雲中的Maven構建配置： 任務創建：新建構建任務時，需輸入任務名稱，並選擇代碼倉庫和分支。 歸檔路徑與類型：歸檔路徑和類型應與項目目錄結構和pom文件設定一致，確保構建產物的正確歸檔。 參數配置：在基本信息中設定執行參數，包括包名、版本號、分組和打包類型。代碼配置需選擇構建倉庫和分支，支持自動構建以檢測代碼變動並觸發編譯。 構建環境：選擇Java和Maven作為構建環境，配置Maven版本、是否發布到私有庫、Maven參數以及pom文件路徑。 屬性與JVM選項：屬性配置包含Maven版本管理屬性，確保參數無空格，屬性間用空格分隔。JVM選項設置用於解決內存溢出問題，可調整PermGen區大小。

3. Maven在華為軟體開發雲中的構建流程： 構建後參數配置：定義包名、版本號、文件路徑、分組和打包類型，多倉庫構建時需重復配置。 構建計劃配置：提供不定時、每日和每周構建選項，可設置構建時長限制。 執行構建：根據需求填寫參數並啟動構建，通過Maven實現自動化構建流程。

4. Maven作為依賴管理和項目管理工具的作用： 依賴管理：Maven提供中央倉庫自動下載構件的功能，解決依賴增多、版本不一致、沖突和臃腫等問題。通過坐標系統精確定位構件，提供免費的全球中央倉庫和快速搜索功能。 項目管理：Maven簡化了項目管理流程，提升了開發效率，使開發者能夠更專注於業務邏輯的實現。

綜上所述，華為軟體開發雲中的Maven編譯構建是一個高效、自動化且可擴展的構建過程，通過Maven的依賴管理和項目管理功能，能夠顯著提升軟體開發的效率和質量。

3. maven依賴＜scope＞作用域詳解

1、compile

在不設置scope標簽的情況下，默認的作用域是compile。compile表示依賴項目需要參與當前項目的編譯，並隨後的測試和運行周期也會使用到，這是一種較為嚴格的依賴類型。在打包時，通常需要將此類依賴包含在內，但請注意，打包還需要插件的支持。

2、test

當scope設置為test時，依賴項目僅參與測試相關的工作，包括測試代碼的編譯和執行。例如，JUnit就是一個典型的test作用域的依賴。

3、runtime

runtime作用域表示依賴項目不需要參與項目的編譯，但會在後續的測試和運行周期中使用。與compile相比，它僅跳過了編譯階段。

4、provided

當依賴項目的scope設置為provided時，它將參與編譯，但在打包時不會將其包含在內。這意味著，如果其他項目需要引用這個依賴，引用的項目必須包含該依賴的相應scope，否則可能會出現問題。

5、system

當依賴項的scope設置為system時，它不會從maven倉庫抓取，而是從本地文件系統獲取，需要配合systemPath屬性一起使用。

4. maven依賴范圍及依賴傳遞

maven依賴范圍是用於控制依賴與三種classpath（編譯、測試、運行）之間的關系，maven提供了以下幾種依賴范圍：

compile：編譯依賴范圍。如果沒有指定，就會默認使用該依賴范圍。使用此依賴范圍的maven依賴，對於編譯、測試、運行三種classpath都有效。典型的例子是spring-core，在編譯、測試、運行時都需要使用該依賴。

test：測試依賴范圍。使用此依賴范圍的maven依賴，只對測試classpath有效，在編譯主代碼或運行項目時無法使用此類依賴。典型的例子就是junit，它只有在編譯測試代碼及運行測試時才需要。

provided：已提供依賴范圍。使用此依賴范圍的maven依賴對於編譯和測試classpath有效，在運行時無效。典型的例子是servlet-api，編譯和測試項目時需要該依賴，但在運行時容器已經提供，就不需要重復引入了。

runtime：運行時依賴范圍。使用此依賴范圍的maven依賴對於測試和運行classpath有效，但在編譯主代碼時無效。典型的例子是JDBC的驅動實現，項目主代碼的編譯只需要JDK提供的JDBC介面，只有在執行測試或運行項目時才需要實現上述介面的具體JDBC驅動。

system：系統依賴范圍。該范圍與三種classpath的關系和provided依賴范圍完全一致。但是使用system范圍的依賴時必須通過systemPath元素顯式地指定依賴文件的路徑。由於此依賴不是通過maven倉庫解析而且與本機系統綁定，可能造成構建的不可移植，因此應該謹慎使用。systemPath元素可以引用環境變數。

import：導入依賴范圍。該依賴范圍不會對三種classpath產生實際的影響。

依賴范圍與classpath的關系如下：

maven引入的傳遞性依賴機制，一方面大大簡化和方便了依賴聲明，另一方面，大部分情況下我們只需要關心項目的直接依賴是什麼，而不用考慮這些直接依賴會引入什麼傳遞性依賴。但有時候，當傳遞性依賴造成問題時，我們就需要清楚地知道該傳遞性依賴是從哪條依賴路徑引入的。

例如，項目A有這樣的依賴關系：A-->B-->C-->X(1.0)、A-->D-->X(2.0)，X是A的傳遞性依賴，但是兩條依賴路徑上有兩個版本的X，那麼哪個X會被maven解析使用呢？兩個版本都被解析顯然是不對的，因為那會造成依賴重復，因此必須選擇一個。maven依賴調解的第一原則：路徑最近者優先。該例中X(1.0)的路徑長度為3，而X(2.0)的路徑長度為2，因此X(2.0)會被解析使用。

依賴調解第一原則不能解決所有問題，比如這樣的依賴關系：A-->B-->Y(1.0)，A-->C-->Y(2.0)，Y(1.0)和Y(2.0)的依賴路徑長度是一樣的，都為2。那麼到底誰會被解析使用呢？在maven2.0.8及之前的版本中，這是不確定的，但是maven2.0.9開始，為了盡可能避免構建的不確定性，maven定義了依賴調解的第二原則：第一聲明者優先。在依賴路徑長度相等的前提下，在POM中依賴聲明的順序決定了誰會被解析使用。順序最靠前的那個依賴優先。