比較下面的兩棵樹。 在這兩種情況下，目標都是擁有一個具有兩個獨立模塊（ frontend和reporting ）和一個共享/公用模塊（ domain ）的應用程序。 frontend的代碼不應訪問reporting代碼，反之亦然。 兩個模塊都可以使用domain代碼。 理想情況下，我們希望在構建時檢查這些訪問規則。

左側是使用Maven構建模塊的傳統解決方案。 每個構建模塊都有一個非常精美的pom.xml ，例如：

<?xml version='1.0' encoding='UTF-8'?> <project xmlns='http://maven.apache.org/POM/4.0.0'xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'xsi:schemaLocation='http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd'><parent><artifactId>parent</artifactId><groupId>org.veripacks.battle</groupId><version>1.0.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><name>Veripacks vs Build Modules: Frontend</name><artifactId>frontend</artifactId><dependencies><dependency><groupId>org.veripacks.battle</groupId><artifactId>domain</artifactId><version>1.0.0-SNAPSHOT</version></dependency></dependencies> </project>

另一方面，只有一個構建模塊，我們的結構要簡單得多。 現在，每個應用程序模塊都對應一個頂級項目程序包（另請參閱有關程序包命名約定的此博客 ）。

注意package-info.java文件。 在那里，使用Veripacks ，我們可以指定哪些包在哪里可見。 首先，我們指定頂級包（ frontend ， reporting和domain ）中的代碼只有在使用@RequiresImport顯式導入時才可訪問。 其次，我們指定要訪問frontend的domain包并使用@Import reporting ； 例如：

@RequiresImport @Import('org.veripacks.battle.domain') package org.veripacks.battle.frontend;import org.veripacks.Import; import org.veripacks.RequiresImport;

現在，Veripacks方法不是更簡單嗎？ 仍然存在構建時檢查，這可以通過運行簡單的測試來實現（有關詳細信息，請參見自述文件）。 另外，您還可以使用其他Veripacks功能，例如@Export批注，它是Package-private范圍的通用版本，并考慮了軟件包的層次結構。 還有其他好處，例如瑣碎的測試代碼共享（對于Maven來說很難），或者重構容易得多（引入新的應用程序模塊只需添加頂層程序包即可）。

出現的直接問題是–第三方圖書館如何？ 最有可能的是，我們希望僅在frontend模塊中可以訪問特定于前端的庫，而在reporting模塊中可以訪問特定于reporting 。 好吧，尚不支持，但好消息–這將是下一個Veripacks版本的范圍。 您可以在GitHub上查看示例項目。

參考： 如何從我們的JCG合作伙伴 Adam Warski的博客（Adam Warski博客） 中用Veripacks替換構建模塊 。

翻譯自: https://www.javacodegeeks.com/2013/03/how-to-replace-a-build-module-with-veripacks.html

總結

以上是生活随笔為你收集整理的如何用Veripacks替换构建模块的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。