Состав проекта Play Framework

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

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

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

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

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

Я вынужден копировать общие шаблоны в оба проекта, я практически не могу писать общие контроллеры, что ОЧЕНЬ раздражает

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


java sbt playframework playframework-2.4
person YoZH    schedule 28.06.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я думаю, вам не следует добавлять основной проект роли в качестве зависимости для двух других проектов. Вы можете разбить основной проект на основные классы и основные ресурсы. Шаблоны и представления в игровой среде представляют собой скомпилированные классы, поэтому вы можете идеально упаковать их в банку. Созданные вами шаблоны будут упакованы вместе с основными классами (или вы также можете разбить их). Вы можете опубликовать эти jar-файлы в зависимом приложении, таком как Artifextory или Nexus, и импортировать их в другие проекты. Что касается ресурсов, вы можете упаковать их, как это делают webjars. Таким образом, вы можете получить к ним доступ из любого другого представления других ваших проектов.

person Augusto    schedule 08.10.2015
comment
Большое спасибо, это интересная идея, но есть ли у вас какой-то конкретный пример, касающийся компиляции и упаковки ресурсов (таких как представления) в отдельный jar? - person YoZH; 08.10.2015
comment
ваши представления должны быть в отдельном проекте. как именно ваши взгляды будут повторно использоваться? о том, как упаковать, см. здесь: scala-sbt. org/0.12.4/docs/Detailed-Topics/Publishing.html . - person Augusto; 08.10.2015
comment
Ну, у меня есть общий набор представлений + статические ресурсы (например, css, js, img), которые используются этими представлениями. И у меня есть несколько основных классов и контроллеров, которые вызывают эти представления. Итак, моя цель - упаковать их каким-то образом, чтобы мне не нужно было копировать их во все проекты, где я хочу их использовать. На самом деле, эти представления и активы образуют административный интерфейс, общий для всех проектов. - person YoZH; 19.10.2015
comment
Эй, я нашел в документации то, что вы хотите сделать :D playframework.com/ документация/2.1.0/SBTSubProjects - person Augusto; 19.10.2015
comment
Проблема с подпроектами заключается в том, что я не могу хранить их в отдельных корнях vcs или это слишком сложно. И мне нужно разделить их точно( - person YoZH; 20.10.2015