Внутренние артефакты принадлежат хранилищу?

Question

Наша команда борется с проблемами, связанными с идеей библиотечного хранилища. Я использовал Maven, и я знаком с Айви. У нас мало сомнений в том, что для сторонних jar общий репозиторий, интегрированный в систему сборки, имеет огромное преимущество.

Борьба заключается в том, как обращаться с артефактами, которые являются строго внутренними. У нас есть много артефактов, которые используют несколько различных инструментов сборки, включая Maven, но по сути они все являются частью одного продукта (одна команда отвечает за все это). К сожалению, в настоящее время мы не производим ни одного артефакта на проект, но мы движемся в этом направлении. Разработчики делают и будут проверять все проекты.

Мы видим два варианта:

1) Относитесь ко всем артефактам, даже внутренним, как к сторонним банкам. Каждый jar создается и публикуется в хранилище, а другие проекты артефактов ссылаются на хранилище для всех проектов.

2) Каждый проект напрямую связан с другими «родственными» проектами. Существует «главный проект», который запускает сборки для всех других проектов с соответствующим порядком зависимостей. В IDE (eclipse) каждый проект напрямую ссылается на свой зависимый проект (источник). Инструменты сборки изучают одноуровневый проект, ссылающийся на .jar.

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

Однако, это добавляет бремени к тому, что вы должны отдельно публиковать изменения. В нашем случае мы просто хотим взять на себя обязательство контроля над источниками (что мы делаем 20-50 раз в день).

Я знаю, что Maven может решить все эти проблемы, но команда НЕ собирается преобразовать все в Maven. Кроме maven, что вы рекомендуете (и почему)?

Answer 1

Нет необходимости выбирать только один из ваших вариантов.Я успешно использую оба в сочетании.Если проект состоит из нескольких модулей, они все собраны вместе, и затем доставляется в хранилище.Однако загрузка происходит только для "официальных" или "релизных" сборок.Сборки текущих разработок выполняются на машинах разработчиков.Вам не нужно использовать Maven для этого.Айви будет работать или даже ручной процесс.«Репозиторий артефактов» может быть одним из превосходных доступных продуктов или просто точкой монтирования файловой системы.

Все дело в определении соответствующих границ компонентов.

Когда вы говорите "разработчики делают и будут проверять все проекты", это нормально.Вы никогда не знаете, когда захотите внести изменения;нет ничего плохого в том, что рабочая копия готова.Но действительно ли вы хотите, чтобы каждый разработчик создавал каждый артефакт локально, даже если им не нужно его менять?Действительно, каждый разработчик меняет каждый артефакт?

А может, у вас просто нет очень большого продукта или очень большой команды.Нет ничего плохого в разработке одного проекта со многими подпроектами (которые могут иметь подмодули).Все работают над всем вместе.Один "построить все" сверху делает свою работу.Просто, работает, быстро (достаточно).Так для чего вы будете использовать общий репозиторий в этом случае?Вероятно, ничего.

Может быть, вам нужно подождать, пока ваш проект / команда не расширится, прежде чем вы увидите какую-либо выгоду от разделения.

Но я гарантирую вам это: у вас есть некоторые фундаментальные компоненты,зависят (прямо или косвенно) от многих проектов, но сами не зависят от каких-либо внутренних артефактов.В идеале эти компоненты не будут сильно меняться в типичном цикле разработки.Мой вам двойной совет:

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

Если такой раскол сработает, вы обнаружите, что перестраиваете этот фундаментальный элемент только тогда, когда это необходимо, и цикл сборки для остальной части проекта (дляваши разработчики) быстрее на соответствующую сумму: win-win.Кроме того, вы сможете использовать другой график доставки (при желании) для основного компонента (-ов), делая изменения в нем более осознанными и контролируемыми (как и должно быть для такого компонента).Это помогает облегчить рост.

Answer 2

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

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

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

Gradle определенно является для вас кандидатом: он может использовать задачи Ant и вызывать сценарии Ant, понимать файлы pom Maven и хорошо обрабатывать мульти-проекты. Maven также может сделать это, и если у вас много терпения, Ant + Ivy может.