Как лучше всего структурировать и создавать приложения Clojure с помощью плагинов?

Я думаю (см. ниже), что хотел бы структурировать проект Clojure как несколько модулей с упорядоченными зависимостями — так же, как Maven позволяет мне делать с многомодульные проекты.

Но я не вижу, как это сделать с Лейнингеном — все, что я вижу, это checkouts исправление, описанное в FAQ который не кажется таким мощным.

Лен сделает это? Должен ли я вместо этого использовать Gradle? Или такая штука не нужна?

Еще немного контекста: мне интересно, как спроектировать модульное приложение, поддерживающее плагины (что, как я полагаю, означает, что банки сбрасываются в путь к классам). И мне интересно, в какой степени я могу структурировать это как ядро ​​​​+ плагины (я думаю, что смогу что-то сделать с Clojure динамическая загрузка кода и не обязательно использовать Java/OSGi). Таким образом, я предполагаю, что основная мотивация для одиночного проекта связана с желанием каким-то образом упаковать все (ядро + плагины по умолчанию) в один большой двоичный объект, который удобен для конечного пользователя, но который также можно разделить. up (и который строится и тестируется фрагментами, проверяя логическую независимость каждого модуля). Более общие советы по этому поводу приветствуются

Обновить

Возможным решением, которое не было упомянуто ниже, является использование плагина Maven. Я предполагаю, что поддерживает все, что делает Maven, но компилирует Clojure, поэтому будет работать с вложенными модулями и т. д.


person andrew cooke    schedule 22.04.2012    source источник


Ответы (1)


Во-первых, похоже, что Leiningen не поддерживает иерархию модулей, как это делает Maven. Кассы - ближайшая вещь, которая у него есть. Однако этого должно быть достаточно для разработки модульного приложения в Clojure.

Для структуры проекта у меня был бы проект API, «основной» проект, сами плагины и отдельный проект упаковки. Ядро и плагины должны зависеть только от API. Какой инструмент сборки вы используете для создания проекта упаковки, зависит от вас. Gradle, вероятно, будет более эффективен при обработке пакетов, однако наличие функции «оформления заказа», которую предлагает Leiningen, может упростить разработку системы в целом.

Я бы взглянул на код Leiningen и Noir, чтобы выяснить, как эффективно с этим справиться.

Для динамической загрузки плагинов я бы начал с просмотра того, как Noir обрабатывает это в двух своих файлах:

  • server.clj имеет загрузку пространства имен для всех файлов под конкретное пространство имен. Под капотом он использует tools.namespace, но вы можете легко увидеть, как он используется для require каждого пространство имен под определенной базой. Таким же образом Leiningen обрабатывает и пользовательские задачи — базовое определение задачи должно находиться в пространстве имен leiningen.$task.
  • core.clj содержит то, что я бы использовал для регистрации плагина . Таким образом, используйте карту под atom и добавьте к этой карте плагины. Я бы посоветовал обернуть регистрацию макросом, чтобы ваш код был чище.

То, что я перечислил выше, должно быть достаточным, если вам не нужно добавлять плагины во время выполнения. Если у вас нет каждого плагина в пути к классам во время запуска, я бы рекомендовал использовать pomegranite для добавления записи в путь к классам. Вы можете увидеть пример в classpath.clj .

person deterb    schedule 23.04.2012