Декларативная обработка зависимостей для многомодульных исходных проектов в системе контроля версий

Question

У нас есть ряд продуктов, которые состоят из большого количества модулей, некоторые из которых разделены между некоторыми из продуктов. Они распределены по нескольким репозиториям контроля версий.

Продукты создаются мастер-скриптами Ant, которые отвечают за проверку всех модулей и сборку их в правильном порядке. Модули не имеют собственных циклов выпуска.

Теперь я бы очень хотел перейти к декларативному управлению зависимостями, но кажется, что все решения (Maven, Ivy) зависят от артефактов, а не от исходного кода под управлением версиями. В зависимости от артефактов все будет у нас на уме, поэтому я бы предпочел этого не делать. Я хотел бы что-то вроде Ivy, но где я могу сказать, что мой продукт зависит от модулей foo, bar и baz (ветка 2.0), и он будет извлекать исходный код из одного или нескольких менеджеров исходного кода (указанных в некоторой конфигурации) для плоское рабочее пространство.

Я планирую использовать gradle для сборки, так что решение, которое соответствует этому, будет высоко ценится ...

Answer 1

Gradle встраивает проект ivy для управления зависимостями, поэтому вы сталкиваетесь с такими же проблемами.

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

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

Предполагая, что вы не контролируете тот факт, что у вас есть несколько репозиториев SCM, я могу рекомендовать следующий подход для создания централизованной сборки (я предполагаю, что вы используете ANT + subversion):

1) Создайте мастер-проект, содержащий ваши дочерние модули

2) Каждый дочерний модуль добавляется в мастер-проект как определение external .Это позволяет одну проверку мастера, в свою очередь, автоматически извлекать каждый дочерний проект

3) Мастер-проект build.xml содержит файл сборки, который использует ivy buildlist задача построить дочерние проекты в правильном порядке на основе объявленных зависимостей в различных дочерних проектах ivy.xml файлы.

Примером многопроектной сборки является здесь

Answer 2

Я думаю, что Refix - это то, что вам нужно: http://refix.codeplex.com/