我有2個使用Maven的項目。第一個是包含實用程序類和方法的庫。第二個項目是將庫作爲依賴項的實際應用程序。我的圖書館在內部使用第三方圖書館。將Maven中的傳遞依賴限制爲運行時範圍
因此，這些都是依賴：
不過，我不希望第三方庫類可在編譯時間在我的應用程序。這是因爲該應用程序由大型團隊支持，並且我希望防止人們意外地使用應用程序中第三方庫中的方法，因爲某些類名稱和某些方法名稱在兩者之間相似。當然，第三部分庫將不得不在我的應用程序中可用運行時。
如果我的所有依賴項的範圍是compile，它不會達到我的目標。有沒有辦法在Maven 3中實現這一點？
非常好的問題，不幸的是，你不能使用Maven 3或2或任何其他版本，因爲它的基本設計。你所問的實際上是一個理想的和理想的行爲，因爲實際上任何神器的依賴關係都應該是可傳遞的，範圍是runtime。但是，這樣的設計會導致一些問題。正如你可以在Maven's Introduction to the Dependency Mechanism約compile範圍閱讀：
它的目的，這應該是運行時間範圍，而不是，讓所有 編譯依賴關係必須被明確列出的 - 但是，沒有圖書館在哪兒，你所依賴的 情況從另一個 庫擴展一個類，迫使你在編譯時可用。對於這個 的原因，編譯時間依賴關係仍然是編譯範圍，即使它們是可傳遞的 。
因此，正如你所看到的，你所需要的實際上是這種行爲的恰當設計，這是不幸的，不可能實現。
在過去三年中沒有任何變化，所以Michal的回答仍然正確：無法限制Maven中的傳遞可見性。
但是，您應該考慮重新設計您的庫以將其拆分爲編譯時依賴項所必需的api-artifact，並且它本身不依賴於第三方庫和僅作爲運行時依賴項需要的實現工件並依賴於第三方庫。
在您的應用程序中，您可以使用「運行時」作用域聲明第三方庫的顯式依賴項。
這可以防止在編譯時看到第三方庫，因此沒有直接的用法可以潛入。但是，它仍然會在運行時出現（因爲它是庫所需要的）。
這是有效的，但很尷尬，值得在pom中解釋XML註釋。
其他答案是正確的。除了通過拆分出來的人造僅API模塊周圍周圍缺少重要的特徵在Maven的工作，你也有這些選擇：
您可以分析依賴一個解決方案：mvn dependency:analyze或有分析爲驗證生命週期階段的一部分依賴關係： https://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html
我希望有辦法做到這一點。謝謝你的回答，米哈爾。 – Juanal
這是幾年前回答的。現在有什麼辦法可以做到這一點嗎？我想知道你是否可以用'import'的範圍在這裏破解一個解決方案？ –
我不認爲這裏有什麼改變。正如我在2012年所說的那樣，這是非常基礎的Maven設計。我相信現在沒有辦法改變這一點，因爲Maven從一開始就是這麼做的。 –