每日必讀DZone News—多版本JAR：好的還是壞的想法？
阿新 • • 發佈：2019-01-05
開發人員不使用單獨的JAR的主要原因是生產和消費不切實際。這個錯誤在構建工具上，直到Gradle，在處理這個問題上已經失敗了。
特別是，使用這個解決方案的開發人員除了依靠Maven的非常差的分類器功能來發布其他工件以外別無選擇。但是，分類器在模擬情況的複雜性方面非常糟糕。它們被用於各種不同的方面，從出版源，文件，javadocs到釋出庫（guava-jdk5，番石榴-jdk7，...）或不同的用法（API，fat JAR，...）的變體。
實際上，沒有辦法指出分類器的依賴關係樹不是專案本身的依賴關係樹。換句話說，POM被破壞了，因為它代表了元件是如何構建的以及它產生了什麼工件。假設你想生成兩個不同的JAR：一個經典的JAR和一個捆綁所有依賴的胖子jar。
解決方案是正確處理變體。這就是我們所說的變體感知依賴管理，Gradle知道如何去做。到目前為止，這個功能只能用於Android開發，但是我們目前正在為Java和本地開發它。
支援變體的依賴管理就是模組和工件是不同的動物。使用相同的原始檔，您可以針對不同的執行時，具有不同的要求。對於本土世界來說，這已經很明顯多年了：我們為i386和amd64編譯，而且沒有辦法將i386庫的依賴和arm64混合在一起！
轉換到Java世界，這意味著如果你的目標是Java 8，你應該生成一個Java 8版本的JAR，其目標類是Java 8類格式。
當然，以前從來沒有人做過，因為處理起來很複雜：Maven肯定不會讓你做這麼複雜的事情。但是Gradle使它成為可能。好訊息是，我們還在開發一種新的元資料格式，讓消費者知道應該使用哪種變體。
簡單地說，構建工具需要處理編譯，測試和打包的複雜性，而且還要消耗這些模組。
例如，假設你想支援Java 8和Java 9作為執行時。那麼，理想情況下，你需要編譯你的庫的兩個版本。這意味著兩個不同的編譯器（為了避免在面向Java 8時使用Java 9 API），兩個不同的類目錄以及兩個不同的JAR。
我們已經在建模方面取得了重大進展，即使我們還沒有準備好，這也解釋了為什麼我們不那麼熱衷於使用多版本的JAR：在解決問題的時候，他們正在修復這個問題， Maven Central將會因為沒有正確宣告其依賴關係的圖書館而臃腫起來！
特別是，使用這個解決方案的開發人員除了依靠Maven的非常差的分類器功能來發布其他工件以外別無選擇。但是，分類器在模擬情況的複雜性方面非常糟糕。它們被用於各種不同的方面，從出版源，文件，javadocs到釋出庫（guava-jdk5，番石榴-jdk7，...）或不同的用法（API，fat JAR，...）的變體。
實際上，沒有辦法指出分類器的依賴關係樹不是專案本身的依賴關係樹。換句話說，POM被破壞了，因為它代表了元件是如何構建的以及它產生了什麼工件。假設你想生成兩個不同的JAR：一個經典的JAR和一個捆綁所有依賴的胖子jar。
解決方案是正確處理變體。這就是我們所說的變體感知依賴管理，Gradle知道如何去做。到目前為止，這個功能只能用於Android開發，但是我們目前正在為Java和本地開發它。
支援變體的依賴管理就是模組和工件是不同的動物。使用相同的原始檔，您可以針對不同的執行時，具有不同的要求。對於本土世界來說，這已經很明顯多年了：我們為i386和amd64編譯，而且沒有辦法將i386庫的依賴和arm64混合在一起！
轉換到Java世界，這意味著如果你的目標是Java 8，你應該生成一個Java 8版本的JAR，其目標類是Java 8類格式。
當然，以前從來沒有人做過，因為處理起來很複雜：Maven肯定不會讓你做這麼複雜的事情。但是Gradle使它成為可能。好訊息是，我們還在開發一種新的元資料格式，讓消費者知道應該使用哪種變體。
簡單地說，構建工具需要處理編譯，測試和打包的複雜性，而且還要消耗這些模組。
例如，假設你想支援Java 8和Java 9作為執行時。那麼，理想情況下，你需要編譯你的庫的兩個版本。這意味著兩個不同的編譯器（為了避免在面向Java 8時使用Java 9 API），兩個不同的類目錄以及兩個不同的JAR。
我們已經在建模方面取得了重大進展，即使我們還沒有準備好，這也解釋了為什麼我們不那麼熱衷於使用多版本的JAR：在解決問題的時候，他們正在修復這個問題， Maven Central將會因為沒有正確宣告其依賴關係的圖書館而臃腫起來！