Блог

Я пытаюсь пересмотреть свой процесс сборки, чтобы использовать ant с apache ivy для моих личных проектов. Они состоят из нескольких общих модулей и нескольких прикладных модулей, которые зависят от общих модулей. Ради этого поста давайте упростим и скажем, что у меня есть общий модуль ( common ) и модуль приложения ( application ), который зависит от common . Каждый модуль имеет свой собственный эффективный репозиторий svn:

 svn_repo_1/common/trunk
                 /branches
                 /tags
svn_repo_2/application/trunk
                      /branches
                      /tags
  

Я проверяю соответствующую редакцию в общей рабочей области в плоской структуре:

 workspace/common
workspace/application
  

В общем, application это будет зависеть от опубликованной версии common , поэтому при сборке common не будет необходимости в сборке. ………. application

Однако, когда мне нужно добавить новую функциональность к common тому, что требуется application , я хотел бы application зависеть от последней common сборки из моей рабочей области (без необходимости публиковать common в моем репозитории).

Я предположил, что это то, что latest.integration имелось в виду (т. е. изменение application ivy.xml указать latest.integration для общей ревизии). Я намеревался использовать задачу ivy buildlist для поиска локальных модулей, которые необходимо было собрать перед сборкой приложения. Однако это не работает, поскольку buildlist задача, похоже, включает common/build.xml запись независимо от того, является ли приложение ivy.xml в файле указывается последняя версия.integration или какая-либо другая опубликованная редакция.

Я был бы признателен за любые предложения. Я испытываю трудности с документацией и примерами ivy, поэтому любые примеры из реального мира также были бы полезны. Примечание: Меня здесь не интересует решение Maven.

Вау, это действительно дежавю! Вернитесь к некоторым из моих первых вопросов на этом сайте 3-4 месяца назад, и почти все они связаны с Ivy! Я на 100% разделяю ваше мнение о том, что Ivy — сложный зверь для изучения и приручения, но после профессионального использования в течение нескольких месяцев я больше никогда не буду развиваться без него. Итак, мой первый совет: продолжайте. Рано или поздно та небольшая (практическая) документация, которую вы найдете на Apache Ivy, начнет приобретать смысл и попадет в игру.

Я могу понять, что могут быть смягчающие причины, по которым вы не хотите публиковать свой common в своем репозитории. Однако, если вы новичок в управлении переходными зависимостями, первый практический совет, который я могу вам дать, заключается в том, что вы должны всегда публиковать свои JARS / WARs / что угодно в своем репозитории; не промежуточная «интеграция», локальная для вашего рабочего пространства.

Причина этого проста: Ivy имеет возможность обхода репозиториев, которые вы определяете в своем файле настроек (в основном). Если вы намеренно сохраняете JAR like common за пределами одного из этих определенных репозиториев, то: (а) у Ivy нет способа разрешить транзитивные зависимости (его основная задача), и (б) «нижестоящие» (зависимые) JAR не могут динамически обновляться при каждой настройке common . Таким образом, использование Ivy только для того, чтобы не публиковать JARS, немного контрпродуктивно; Я удивлен, что Ivy даже включает это в качестве функции.

Думаю, мне нужно было бы понять вашу мотивацию отказа от публикации common . Если у вас просто возникли проблемы с выполнением ivy:publish задачи, не беспокойтесь, я могу предоставить множество примеров, которые помогут вам начать. Но если есть какие-то другие причины, то я прошу вас рассмотреть это решение: настройте несколько репозиториев.

Возможно, у вас есть один «первичный» репозиторий, где публикуется в основном все; и затем у вас есть «вторичный» или «промежуточный» репозиторий, где вы публикуете common всякий раз, когда это имеет смысл (для вас) делать это. Затем вы можете настроить сборку Ant с помощью двух разных задач публикации, таких как публикация-основная и публикация-интеграция.

Таким образом, вы получаете лучшее из обоих миров: вы получаете промежуточную промежуточную область и можете держать все под мощным контролем Ivy.