如何用Veripacks替换构建模块

比较下面的两棵树。在这两种情况下，目标都是拥有一个具有两个独立模块（ frontend和reporting ）和一个共享/公用模块（ domain ）的应用程序。 frontend的代码不应访问reporting代码，反之亦然。两个模块都可以使用domain代码。理想情况下，我们希望在构建时检查这些访问规则。

2013-03-20_1910

左侧是使用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替换构建模块。