Муравей / Плющ для строительства проекта

Question

Я рассматриваю вопрос о переключении проекта Maven, которым я управляю, на Apache-Ant / Ivy.Мне нужно больше контролировать процесс сборки, и я очень разочарован в Maven.Пожалуйста, никаких комментариев о том, как велик Maven.У меня вопрос по поводу Ivy.

Я бы хотел установить «стандартный» шаблон сборки Ant, который впоследствии можно будет использовать для других проектов с минимальными изменениями.

«Я настроу центральный»корпоративный репозиторий, где мы можем разместить сторонние библиотеки, которые недоступны в общедоступных репозиториях Maven (например, коммерческие библиотеки, библиотеки Sun, проприетарные библиотеки и т. д.).Этот корпоративный репозиторий будет доступен в нашей локальной сети, но может быть недоступен за пределами офиса.

У каждого разработчика будет свой личный репозиторий в ~/.ivy/repository.Я хотел бы, чтобы сборка Ant автоматически обновляла этот частный репозиторий, изменяя версии библиотек из корпоративного репозитория.

В ~/.ivy/ant я планирую разместить «стандартные» модули для включения в отдельный проект build.xmlфайлы, используя задачу include в Ant 1.8.Эти модули будут обеспечивать такие вещи, как цели компиляции Scala и Clojure с разными версиями для разных версий Scala и Clojure (например: scala-compile-2.9.1.xml, clojure-compile-1.3.xml и т. Д.). Модули сборки будут доступны в репозитории предприятия и должныобновляться автоматически в частных репозиториях, если они изменяются.

Каждый проект будет следовать стандартной структуре каталогов Maven: ${project}/src/main/java, ${project}/target/classes и т. д.

В прошлом я пытался использоватьПлющ, но файлы сборки Ant должны быть очень большими (> 500 строк для файла сборки шаблона) и сложными в управлении / редактировании.Я надеюсь, что, поместив стандартные цели в их собственные модули сборки в каталог ~/.ivy/ant, я смогу избежать этого раздувания кода.

Можно ли это сделать?Я далеко от базы?Единственная документация, которую я могу найти на Ivy, находится на веб-сайте Apache (http://ant.apache.org/ivy). Есть ли другая доступная документация, включая книги?

Answer 1

Довольно разумная идея о разделении файла сборки шаблона на включаемые вспомогательные файлы. Лично я теперь переключаю действительно большой проект с муравья (никакого управления зависимостями вообще - только копирование файлов с ftp) на решение муравья / плюща. Итак, я сделал так - у меня есть файл с целями вехи - то есть готов к компиляции, скомпилирован, готов к архивации, заархивирован - и так далее. Я думаю, у тебя есть идея. Я настроил зависимости всех этих целей (зависимости в терминах ant, не поймите меня неправильно). Таким образом - скомпилированный зависит от готовности к компиляции, готовый к компиляции зависит от инициализированного - что-то вроде этого. Эти цели не имеют тела - они предназначены для включения в каждый файл сборки каждого модуля вашего многомодульного проекта. Единственная цель этой цели - поддерживать состояние сборки, из-за этого вещи импорта становятся довольно хитрыми, и трудно понять, какая цель была переопределена, и когда эта цель будет запущена. Но с этим файлом я могу легко изменить состояние сборки на каждом разумном этапе. Я хочу в одном модуле скомпилировать файлы справки с Exteran Exe. Нет проблем - в этом проекте я просто делаю это - готовность к архивированию зависит от цели составления справки. И так как цели этого этапа включены - я могу переопределить только некоторые из них - все остальные будут использовать желаемый способ построения проекта.

Другая часть моей стратегии - файлы сборки миксинов - для каждой конкретной области. Так что у меня есть файл для плюща. Там я ставлю инициализацию, разрешение, публикацию и так далее. Когда я хочу использовать ivy - я просто включаю этот файл и управляю зависимостями через мои цели. Если сборка типичная - я только включаю этот файл и обладаю условно-расширенной функциональностью. Все из коробки. Как?? Просто сочетается с другими миксинами. Миксины могут включать другие миксины в зависимости от них. Таким образом, каждый миксин является частью моей стратегии сборки. Вещи из ООП - единичное дело. В вашем случае это миксин скала с целями, специфичными для вещей скала.

Тогда у меня делегат.xml, который делегирует дочерним проектам общие действия по сборке. У меня есть dist, all, test и все, что вы хотите для многомодульного проекта. Порядок сборки оценивается с помощью списка задач ant-ivy.

Там также есть некоторые другие файлы - но это стратегически основные файлы, которые помогли мне получить многоразовую и удобную сборку в этом БОЛЬШОМ и ОЧЕНЬ консервативном проекте. Так что, если вас интересуют детали, не стесняйтесь и свяжитесь со мной. Я буду очень рад помочь вам, потому что документы на ivy действительно сложны и неполны.

РЕДАКТИРОВАТЬ: О книгах - Ant in Action может помочь вам, я взял несколько идей из этой книги, и я очень рекомендую всем прочитать. Там ты тоже можешь найти плющ. А насчет документации по ivy - извините, это все, что доступно. Но когда у меня возникли проблемы с этим громоздким плющом и муравьем, я нашел несколько интересных статей в частных блогах. Так что ... это может каким-то образом заполнить пробел.