Управление несколькими внутренними проектами с помощью Maven (переключение с ant / ivy) - PullRequest
1 голос
/ 19 сентября 2010

Позвольте мне сначала объяснить нашу инфраструктуру.

Моя компания производит два корпоративных программных продукта (каждый из которых, в свою очередь, включает в себя несколько серверов).Давайте назовем их ProductA и ProductB.

ProductA состоит из 40 отдельных проектов, которые разветвляются вместе, но все они построены отдельно и рассматриваются как отдельные единицы.Поскольку каждый из этих проектов создает большое дерево зависимостей, мы используем Ivy / Ant для управления нашими зависимостями. TeamA постоянно модифицирует все эти проекты, иногда обратно несовместимыми способами, поэтому мы публикуем все для плюща как (пример) 1.0.0.SVN_REV.Когда мы зависим от чего-то, мы говорим 1.0.0.+ и используем средство разрешения конфликтов, которое дает нам совместимый набор зависимостей.

Представьте себе граф зависимостей, например:

W -> X -> Y
       \
        -> Z
       /
     V

Когда наш верхний уровеньпроект зависит от W 1.0.0.+ и V 1.0.0.+, мы можем не получить последний V, так как последний W может быть еще не собран с последним Z, поэтому Айви выселяет последний V, принимая 1.0.0.9 вместо 1.0.0.10, поскольку последние W и V 1.0.0.9 зависят от Z v1.0.0.6 Все эти сборки основаны на Bamboo, причем зависимости настроены для запуска дочерних сборок при необходимости, и, таким образом, каждый из этих проектов создается отдельно.

Итак, учитывая эту настройку, Айви гарантирует, что все наши зависимости для сборки верхнего уровня совместимы в двоичном формате.Теперь сборке верхнего уровня может потребоваться последняя версия V для правильной компиляции, поэтому произойдет сбой с ошибкой компиляции, но если компиляция прошла успешно, мы бы точно знали, что все зависимости совместимы в двоичном формате и что QA не будетпотратьте время на установку 8 серверов, чтобы выяснить, что какой-то метод отсутствует, когда W вызывает Z.

ProductB использует около 30 из этих проектов, но вместо последнего он ждет ProductA Команда QA сертифицирует релиз, а затем начинает использовать эти зависимости.

Совершенно очевидно, как Maven будет работать для ProductB, поскольку они всегда зависят от неизменного набора зависимостей.

Итак, Чтобы понять суть вопроса , при оценке Maven я вижу, как SNAPSHOT зависимости и публикации дают нам основную структуру.Однако я не знаю или не понимаю, является ли Maven при публикации W изменяет ли он POM, чтобы заполнить явный использованный SNAPSHOT, или он просто говорит, что W зависит от X-1.0.0-SNAPSHOT?

И если он не заменит точно используемый X, как я могу получить те же бинарные совместимые гарантии, которые дает мне Айви?

Единственный очевидный ответ - взять одного гигантапостроить, чтобы сделать все 40 проектов, но это займет значительное время, когда проект верхнего уровня является единственным изменением.Если бы было 30 минут, чтобы сделать über-компиляцию, я бы, вероятно, увидел 5-10 коммитов на сборку, что затруднило бы оценку, какой разработчик сломал сборку. В общем, я ищу другое решение, чем это.

1 Ответ

0 голосов
/ 20 сентября 2010

Когда ivy публикуется в репозиторий, можно по желанию указать версию выпуска

<ivy:publish resolver="shared" pubrevision="1.0" status="release">
   <artifacts pattern="dist/[artifact].[ext]" />
</ivy:publish>

Самое замечательное в ivy - это то, что он генерирует и публикует файл "ivy.xml", который будет иметь все динамические версии.номера разрешены на момент публикации.Все это вы, наверное, уже знаете.

Удивительно, но Мейвену нужно больше работать.Вам потребуются плагины, которые будут локально редактировать ваше POM (и, если у вас есть дочерние модули, их POM также).Для получения более подробной информации см. Следующие плагины

Так что вам нужно убедиться, что ваши POM-ы являются кошерными, прежде чемвызывая "mvn deploy".

Если честно, я не полностью отказался от своих сборок на основе ivy, потому что мне трудно эмулировать простую поддержку ivy динамических взаимозависимостей модулей.Я уверен, что это возможно, как я уже сказал, кажется, что это больше работы, когда вы привыкли работать с плющом.

Чтобы облегчить переход с ivy на Maven, рассматривали ли вы возможность создания POM-модулей с использованием ivy?Для меня очень хорошо работает следующее:

<ivy:deliver deliverpattern="dist/ivy.xml" pubrevision="1.0" status="release"/>
<ivy:makepom ivyfile="dist/ivy.xml" pomfile="dist/pom.xml">
    <mapping conf="default" scope="compile"/>
    <mapping conf="runtime" scope="runtime"/>
</ivy:makepom>

Задача delivery разрешит все динамические зависимости и создаст файл ivy, который можно использовать для создания POM maven.Затем это POM публикуется вместе со стандартным артефактом ваших модулей, и его необходимо указать в файле ivy:

<ivy-module ..
..
    <publications>
         <artifact name="mymod" type="war" conf="master" />
         <artifact name="pom"   type="pom" ext="xml" conf="master" />
    </publications>

Убедитесь, что вы используете версию 2.2.0 ivy и стандартную задачу публикации ivy (см.выше) не должно возникнуть проблем при загрузке вашего артефакта и сгенерированного POM

...