Композиция проекта Play Framework

Question

У меня есть 2 проекта, которые разработаны с использованием PlayFramework 2.4. Хотя они полностью разделены по своей концепции, они имеют общие функции, такие как управление эволюцией (Liquibase), административный механизм CRUD, механизм уведомления (электронная почта, смс) и т. Д. Таким образом, было решено разделить каждый проект на 2 модуля: ядро ", в котором хранится все описанная логика и модуль" project ", в котором содержатся специализированные сервисы, шаблоны, представления.

Рекомендованный подход для достижения этой цели в Play Framework является концепцией «подпроекта». Но это явно не вариант, из-за, по крайней мере по двум причинам:

1. Проекты разрабатываются разными группами, поэтому они не могут быть расположены в одной структуре каталогов
2. Эти 3 модуля («ядро» и 2 "проектных" модуля) ДОЛЖНЫ быть версией в отдельных репозиториях VCS (Mercurial)

Мое настоящее решение - создать основной модуль и обеспечить его как зависимость от приложения «Project» Play. , Хотя этот подход частично работает, существуют серьезные недостатки:

1. Если добавить файл маршрутов в модуле, они будут переопределены проекта маршруты файл
2. Вы наклоняетесь вид на место в основном модуле, потому что из-за вас рис.1 косяк доступа государственные активы
3. Из-за недостижения N.1 и 2, вы не можете место контроллеры в основном модуле, потому что вы не можете указать вид для отображения
4. статических активов (публичный каталог) не включен в дистрибутив модуля

Я вынужден копировать общие шаблоны в оба проекта, я практически не могу писать общие контроллеры, которые раздражают SO much

Цените любую помощь. Может быть, это может быть достигнуто в какой-то высокостандартной сборке и публикации для основного модуля?

Answer 1

Я думаю, вы не должны добавлять основной проект роли в качестве зависимости для других 2 проектов. Вы можете разбить основной проект на основные классы и основные ресурсы. Шаблоны и представления в игровой структуре - это скомпилированные классы, поэтому вы можете упаковать их в банку отлично. Шаблоны, которые вы создаете, будут упакованы вместе с основными классами (или вы можете их разбить). Вы можете опубликовать эти банки в приложение зависимости, например artifactory или nexus, и импортировать в другие проекты. Для ресурсов вы можете упаковать их, как webjars. Таким образом, вы можете получить к ним доступ из любого другого вида ваших других проектов.