Что мешает ей же сформировать запрос на поиск пакетов в репозитории, а не самостоятельно с индексами возиться?
·>Репозиториев может быть несколько. Запросы надо слать ко всем. Это будет тормозить. И представь себе какая должна быть мощная инфра.
По моим субъективным ощущениям, с пакетами maven работает медленнее, чем NuGet, и возни с ним больше.
·>Ты так написал.
Или ты это придумал. Подрядчик у себя на своей инфраструктуре как-то собирал же бинарники.
·>Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.
Каких ещё наёмных работников? Обычный такой случай, когда одна компания заказывает у другой разработку ПО.
Или все всегда нанимают себе штат программистов, чтобы они всё на свете делали?
·>Почему тебя Newtonsoft билд-сервера не беспокоят?
Потому что это массовый продукт, по которому можно у людей спросить и сообща разобраться, если будут какие-то проблемы.
Ну и повторяю, что за его исходники я не платил, а когда компания нанимает другую, то обычно хочет иметь исходники проекта,
чтобы потом его можно было развивать и не обязательно силами того же подрядчика.
·>Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.
Так надо было собирать у себя, чтобы всегда было рабочее окружение в наличии и точно знать, что тесты есть, проходят, проект собирается.
Ты же мне рассказываешь, что так нормально, разработчик у себя на своей инфраструктуре должен собирать и отдавать готовое.
А как заказчику проверять, что ему реальные исходники прислали, а не набор файлов?
По-моему тут проще заказчику собирать присланные исходники и тестировать получившийся результат, а не верить подрядчику и брать его бинарники.
·>Ну да. У вас ничего больше и не было, и у вас таки всё заработало через неделю. ЧТД.
Только этот pom.xml пришлось редактировать и исходники править.
Если бы pom.xml отсутствовал, то времени ушло на 10 минут больше, т.к. пришлось бы ещё прописать зависимости, исходя из директив import.
·>А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?
При желании это всё пробрасывается через AD централизованно и не нужно лазить по всем проектам и там переписывать адрес репозитория.
Вопрос в выбранной организации инфраструктуры.
Для NuGet тоже можно в каждый проект конфиг положить и поиметь те же плюсы и минусы.
·>А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?
В приличных заведениях есть базы знаний. Подозреваю, что кто осилил автоматизировать сборку, PR и т.п. завёл хотя бы уж какую wiki и минимальную документацию, которой сможет воспользоваться новый сотрудник.
Всё равно всегда будут нюансы типа настройки VPN на домашнем компе, которые придётся документировать.
Даже если будет подготовлен скрипт, который сам всё сделает, нужно его куда-то положить и написать где брать, как запускать.
·>А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.
Каждый сотрудник пишет этот сложный сценарий сборки? Ну, вот Java-джуна возьмём и он на maven сможет изобразить что-то?
Или всё же он сможет только зависимость добавить и на этом всё?
На MSBuild тоже народ делает сложные сценарии, только не думаю, что таких людей очень много.
Лично мне удобнее писать на каком-нибудь Powershell или Cake, чем возиться с xml, но тут опять вопрос предпочтений.
Ну, и сложные сценарии именно сборки достаточно редко встречаются.
Основные сложности идут в собирании всего в кучу, когда разные версии инсталляторов нужно собрать, разные какие-то ресурсы добавить, завесить собранный комплект куда-то на сервер и т.д.
Сама сборка у меня как-то обычно разруливается простой передачей ключей/профилей, а не нагромождением чего-то сложного.
Можно конечно в одну кучу собрать и компиляцию и деплой, но по-моему это в итоге неудобно и превращается в кашу.
