Сравните два дерева ниже. В обоих случаях цель состоит в том, чтобы иметь приложение с двумя независимыми модулями ( frontend и reporting ) и одним общим / общим модулем ( domain ). Код в frontend не должен иметь доступа к коду в reporting , и наоборот. Оба модуля могут использовать код domain . В идеале мы хотели бы проверить эти правила доступа во время сборки.
Слева — традиционное решение, использующее модули сборки Maven. Каждый модуль сборки имеет довольно сложный pom.xml , например:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<?xml version='1.0' encoding='UTF-8'?> <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 . Во-вторых, мы указываем, что мы хотим получить доступ к пакету domain во @Import frontend и @Import reporting с помощью @Import ; например:
|
1
2
3
4
5
6
|
@RequiresImport@Import('org.veripacks.battle.domain')package org.veripacks.battle.frontend;import org.veripacks.Import;import org.veripacks.RequiresImport; |
Разве подход Veripacks не проще? Все еще есть проверка во время сборки, которая возможна при запуске простого теста (подробности см. В README). Кроме того, вы также можете использовать другие функции Veripacks, такие как аннотации @Export , которые являются обобщенной версией частной области пакета, с учетом иерархии пакетов. Есть и другие преимущества, такие как простое совместное использование тестового кода (что довольно сложно с Maven) или гораздо более простой рефакторинг (введение нового модуля приложения — это добавление пакета верхнего уровня).
Возникает непосредственный вопрос: а как насчет сторонних библиотек? Скорее всего, мы бы хотели, чтобы специфичные для внешнего интерфейса библиотеки были доступны только в модуле frontend , а специфичные для reporting модуле reporting . Ну, пока не поддерживается, но хорошие новости — это будет темой следующего выпуска Veripacks. Вы можете просмотреть примеры проектов на GitHub .
Ссылка: Как заменить модуль сборки Veripacks от нашего партнера JCG Адама Варски в блоге Блог Адама Варски .