Ограничить зависимости между пакетами Java

Думаю, у Checkstyle есть чек на это. Это называется Контроль импорта

Eclipse поддерживает это через свойства Build Path / свойства jar. Я думаю, что это может работать только через границы банка / проекта.

Вы можете настроить проекты Eclipse, чтобы указать правила доступа. В правилах доступа могут быть указаны уровни «Запрещено», «Не рекомендуется» и «Доступно» с использованием правил подстановки. Затем вы можете настроить нарушения режима «Не рекомендуется» или «Запрещено» отмечать как предупреждения или ошибки во время сборки.

Вид старой статьи по идее (подробности могут быть устаревшими):

http://www.eclipsezone.com/eclipse/forums/t53736.html

Если вы используете плагины Eclipse (или OSGi), то «общедоступные» части плагина / модуля явно определены, и это часть модели.

плющ кажется хорошим решением вашей проблемы (если вы используете ant). Ivy - это официальный компонент Ant для управления зависимостями, поэтому он прекрасно интегрируется с ant. Он способен разрешать зависимости, обрабатывать конфликты, создавать исключения и так далее.

Он использует простую структуру xml для описания зависимостей и его проще использовать, чем Maven, потому что он пытается только решать проблемы разрешения зависимостей.

С домашней страницы Ivy:

Ivy - это инструмент для управления (записи, отслеживания, разрешения и отчетности) зависимостей проекта. Для него характерно следующее:

1. гибкость и настраиваемость - Ivy по сути не зависит от процесса и не привязан к какой-либо методологии или структуре. Вместо этого он обеспечивает необходимую гибкость и настраиваемость для адаптации к широкому спектру процессов управления зависимостями и сборки.
2. тесная интеграция с Apache Ant - несмотря на то, что Ivy доступен как отдельный инструмент, он особенно хорошо работает с Apache Ant, предоставляя ряд мощных задач Ant, начиная от разрешения зависимостей и заканчивая отчетом и публикацией зависимостей.

Для конкретных решений IDE в IntelliJ IDEA есть инструмент анализа зависимостей, который также позволяет определять недопустимые зависимости. http://www.jetbrains.com/idea/webhelp2/dependency-validation-dialog.html

Нарушение зависимости будет отображаться как при компиляции, так и в реальном времени при редактировании зависимого класса (в виде полос ошибок / предупреждений на правой панели ошибок).

Еще больше автоматизации можно получить с помощью сервера сборки JetBrains TeamCity, который может запускать сборки для проверки и сообщать о настроенных выше проверках.

Для другого независимого от IDE решения AspectJ можно использовать для объявления недопустимых зависимостей (и интеграции шага в процесс сборки, чтобы получить информацию о предупреждениях / ошибках для проблем).

Вы можете использовать несколько модулей в IDEA или Maven или несколько проектов в Eclipse и Gradle. Концепция во всех случаях одинакова.

Тривиальной интерпретацией был бы модуль для myapp.server.bl и другой для myapp.client.ui.customlayout без каких-либо зависимостей времени компиляции между ними. Теперь любая попытка скомпилировать код или завершить код для противоположного модуля / проекта будет неудачной по желанию.

Чтобы проверить, насколько серьезна проблема, полезной отправной точкой для IntelliJ IDEA является Анализ зависимостей:

http://www.jetbrains.com/idea/webhelp/analyzing-dependencies.html

Из этой статьи вы узнаете, как выполнять анализ зависимостей для вашего проекта и как действовать при этом.

Возможно, можно использовать Классный велосипед: http://classycle.sourceforge.net/ddf.html