Здравствуйте, karbofos42, Вы писали:

K>·>IDE.
K>Что мешает ей же сформировать запрос на поиск пакетов в репозитории, а не самостоятельно с индексами возиться?
Сеть. Медленная и ненадёжная.

K>По моим субъективным ощущениям, с пакетами maven работает медленнее, чем NuGet, и возни с ним больше.
Субъективные ощущения обсуждать не берусь.

K>·>Ты так написал.
K>Или ты это придумал. Подрядчик у себя на своей инфраструктуре как-то собирал же бинарники.
Ты же не знаешь как, информации у тебя не было. Он мог собирать у себя на компе в Студии и зиповать бинарики.

K>·>Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.
K>Каких ещё наёмных работников? Обычный такой случай, когда одна компания заказывает у другой разработку ПО.
K>Или все всегда нанимают себе штат программистов, чтобы они всё на свете делали?
Другая компания имеет свой QA и менеджеров, которые должны следить за процессом и заботиться о качестве продукта.

K>·>Почему тебя Newtonsoft билд-сервера не беспокоят?
K>Потому что это массовый продукт, по которому можно у людей спросить и сообща разобраться, если будут какие-то проблемы.
Т.е. профессионалам нанятым за деньги не доверяем. Своим штатным специалистам, подписывающим акты, не доверяем. А массовке доверяем. Ну надо что-то в консерватории менять.

K>Ну и повторяю, что за его исходники я не платил, а когда компания нанимает другую, то обычно хочет иметь исходники проекта,
K>чтобы потом его можно было развивать и не обязательно силами того же подрядчика.
Ну по актам исходники у вас были. Что не устраивает неясно.

K>·>Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.
K>Так надо было собирать у себя, чтобы всегда было рабочее окружение в наличии и точно знать, что тесты есть, проходят, проект собирается.
K>Ты же мне рассказываешь, что так нормально, разработчик у себя на своей инфраструктуре должен собирать и отдавать готовое.
Да, это нормально. Если вы хотите владеть продуктом, то он у вас и должен хоститься. Пусть исполнители пушат в ваш git и у вас всё собирается и деплоится в ваши же репы бинарей.

K>А как заказчику проверять, что ему реальные исходники прислали, а не набор файлов?
Акты подписать, ясен пень.

K>По-моему тут проще заказчику собирать присланные исходники и тестировать получившийся результат, а не верить подрядчику и брать его бинарники.
Ну вы верили зачем-то, а виноват мавен.

K>·>Ну да. У вас ничего больше и не было, и у вас таки всё заработало через неделю. ЧТД.
K>Только этот pom.xml пришлось редактировать и исходники править.
И? А требуемая тобой "приличная база знаний" была? Нет ведь? Хватило таки pom.xml.

K>Если бы pom.xml отсутствовал, то времени ушло на 10 минут больше, т.к. пришлось бы ещё прописать зависимости, исходя из директив import.
Ага-ага. И что ж вы его не удалили, чтоб облегчить себе задачу? Заврался ты, гражданин.

K>·>А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?
K>При желании это всё пробрасывается через AD централизованно и не нужно лазить по всем проектам и там переписывать адрес репозитория.
Не только при желании, но и при возможности, да. Я тебе про settings.xml уже рассказал. Мавен же не ограничивает мир централизованным сценарием. Можно иметь распределённую систему между разными командами, организациями и т.д.

K>Вопрос в выбранной организации инфраструктуры.
Угу.

K>Для NuGet тоже можно в каждый проект конфиг положить и поиметь те же плюсы и минусы.
Думаю да. О чём спор тогда, неясно. В pom.xml тоже вовсе не обязательно прописывать всё что только можно.

K>·>А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?
K>В приличных заведениях есть базы знаний. Подозреваю, что кто осилил автоматизировать сборку, PR и т.п. завёл хотя бы уж какую wiki и минимальную документацию, которой сможет воспользоваться новый сотрудник.
Именно, что минимальную — где брать исходники, и собственно всё.

K>Всё равно всегда будут нюансы типа настройки VPN на домашнем компе, которые придётся документировать.
K>Даже если будет подготовлен скрипт, который сам всё сделает, нужно его куда-то положить и написать где брать, как запускать.
Угу. Это и надо.

K>·>А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.
K>Каждый сотрудник пишет этот сложный сценарий сборки?
Зачем?

K>Ну, вот Java-джуна возьмём и он на maven сможет изобразить что-то?
Ну мидл, думаю, сможет.

K>Или всё же он сможет только зависимость добавить и на этом всё?
Да много что сможет. Например, добавить плагин для сборки docker-images приложений или кодогенерацию какую-нибудь вроде protobuf, и всякие чекеры, валидаторы и т.п. Плагинов сотни.

K>На MSBuild тоже народ делает сложные сценарии, только не думаю, что таких людей очень много.
Ну таких людей много и не надо. Вот Google напрягся и выкатил плагин для docker, и теперь любой мидл это может делать за минуту без знаний, Dockerfile, Powershell или Cake или ещё чего.

K>Лично мне удобнее писать на каком-нибудь Powershell или Cake,
Оппа. Именно, что помимо msbuild нужны ещё какие-то тулзы, настройки, базы знаний и "кто-то один на проекте это всё будет настраивать". Попадёт этот один под автобус и будете разгребать неделями его магические скрипты, копаясь в базах знаний.

K>чем возиться с xml, но тут опять вопрос предпочтений.
Ну xml там это только конфигурация. pom.xml совсем не то же, что .csproj. Сами плагины пишутся на любом jvm языке.

K>Ну, и сложные сценарии именно сборки достаточно редко встречаются.
Ну так и сложные pom.xml тоже редко встречаются.

K>Основные сложности идут в собирании всего в кучу, когда разные версии инсталляторов нужно собрать, разные какие-то ресурсы добавить, завесить собранный комплект куда-то на сервер и т.д.
K>Сама сборка у меня как-то обычно разруливается простой передачей ключей/профилей, а не нагромождением чего-то сложного.
K>Можно конечно в одну кучу собрать и компиляцию и деплой, но по-моему это в итоге неудобно и превращается в кашу.
"Базы знаний" из состояния каши вообще никогда выходят.

Здравствуйте, karbofos42, Вы писали:

K>·>IDE.
K>Что мешает ей же сформировать запрос на поиск пакетов в репозитории, а не самостоятельно с индексами возиться?
Сеть. Медленная и ненадёжная.

K>По моим субъективным ощущениям, с пакетами maven работает медленнее, чем NuGet, и возни с ним больше.
Субъективные ощущения обсуждать не берусь.

K>·>Ты так написал.
K>Или ты это придумал. Подрядчик у себя на своей инфраструктуре как-то собирал же бинарники.
Ты же не знаешь как, информации у тебя не было. Он мог собирать у себя на компе в Студии и зиповать бинарики.

K>·>Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.
K>Каких ещё наёмных работников? Обычный такой случай, когда одна компания заказывает у другой разработку ПО.
K>Или все всегда нанимают себе штат программистов, чтобы они всё на свете делали?
Другая компания имеет свой QA и менеджеров, которые должны следить за процессом и заботиться о качестве продукта.

K>·>Почему тебя Newtonsoft билд-сервера не беспокоят?
K>Потому что это массовый продукт, по которому можно у людей спросить и сообща разобраться, если будут какие-то проблемы.
Т.е. профессионалам нанятым за деньги не доверяем. Своим штатным специалистам, подписывающим акты, не доверяем. А массовке доверяем. Ну надо что-то в консерватории менять.

K>Ну и повторяю, что за его исходники я не платил, а когда компания нанимает другую, то обычно хочет иметь исходники проекта,
K>чтобы потом его можно было развивать и не обязательно силами того же подрядчика.
Ну по актам исходники у вас были. Что не устраивает неясно.

K>·>Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.
K>Так надо было собирать у себя, чтобы всегда было рабочее окружение в наличии и точно знать, что тесты есть, проходят, проект собирается.
K>Ты же мне рассказываешь, что так нормально, разработчик у себя на своей инфраструктуре должен собирать и отдавать готовое.
Да, это нормально. А если вы хотите владеть продуктом, то он у вас и должен хоститься. Пусть исполнители пушат в ваш git и у вас всё собирается и деплоится в ваши же репы бинарей.

K>А как заказчику проверять, что ему реальные исходники прислали, а не набор файлов?
Акты подписать, ясен пень.

K>По-моему тут проще заказчику собирать присланные исходники и тестировать получившийся результат, а не верить подрядчику и брать его бинарники.
Ну вы верили зачем-то, а виноват мавен.

K>·>Ну да. У вас ничего больше и не было, и у вас таки всё заработало через неделю. ЧТД.
K>Только этот pom.xml пришлось редактировать и исходники править.
И? А требуемая тобой "приличная база знаний" была? Нет ведь? Хватило таки pom.xml.

K>Если бы pom.xml отсутствовал, то времени ушло на 10 минут больше, т.к. пришлось бы ещё прописать зависимости, исходя из директив import.
Ага-ага. И что ж вы его не удалили, чтоб облегчить себе задачу? Заврался ты, гражданин.

K>·>А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?
K>При желании это всё пробрасывается через AD централизованно и не нужно лазить по всем проектам и там переписывать адрес репозитория.
Не только при желании, но и при возможности, да. Я тебе про settings.xml уже рассказал. Мавен же не ограничивает мир централизованным сценарием. Можно иметь распределённую систему между разными командами, организациями и т.д.

K>Вопрос в выбранной организации инфраструктуры.
Угу.

K>Для NuGet тоже можно в каждый проект конфиг положить и поиметь те же плюсы и минусы.
Думаю да. О чём спор тогда, неясно. В pom.xml тоже вовсе не обязательно прописывать всё что только можно.

K>·>А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?
K>В приличных заведениях есть базы знаний. Подозреваю, что кто осилил автоматизировать сборку, PR и т.п. завёл хотя бы уж какую wiki и минимальную документацию, которой сможет воспользоваться новый сотрудник.
Именно, что минимальную — где брать исходники, и собственно всё.

K>Всё равно всегда будут нюансы типа настройки VPN на домашнем компе, которые придётся документировать.
K>Даже если будет подготовлен скрипт, который сам всё сделает, нужно его куда-то положить и написать где брать, как запускать.
Угу. Это и надо.

K>·>А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.
K>Каждый сотрудник пишет этот сложный сценарий сборки?
Зачем?

K>Ну, вот Java-джуна возьмём и он на maven сможет изобразить что-то?
Ну мидл, думаю, сможет.

K>Или всё же он сможет только зависимость добавить и на этом всё?
Да много что сможет. Например, добавить плагин для сборки docker-images приложений или кодогенерацию какую-нибудь вроде protobuf, и всякие чекеры, валидаторы и т.п. Плагинов сотни.

K>На MSBuild тоже народ делает сложные сценарии, только не думаю, что таких людей очень много.
Ну таких людей много и не надо. Вот Google напрягся и выкатил плагин для docker, и теперь любой мидл это может делать за минуту без знаний, Dockerfile, Powershell или Cake или ещё чего.

K>Лично мне удобнее писать на каком-нибудь Powershell или Cake,
Оппа. Именно, что помимо msbuild нужны ещё какие-то тулзы, настройки, базы знаний и "кто-то один на проекте это всё будет настраивать". Попадёт этот один под автобус и будете разгребать неделями его магические скрипты, копаясь в базах знаний.

K>чем возиться с xml, но тут опять вопрос предпочтений.
Ну xml там это только конфигурация. pom.xml совсем не то же, что .csproj. Сами плагины пишутся на любом jvm языке.

K>Ну, и сложные сценарии именно сборки достаточно редко встречаются.
Ну так и сложные pom.xml тоже редко встречаются.

K>Основные сложности идут в собирании всего в кучу, когда разные версии инсталляторов нужно собрать, разные какие-то ресурсы добавить, завесить собранный комплект куда-то на сервер и т.д.
K>Сама сборка у меня как-то обычно разруливается простой передачей ключей/профилей, а не нагромождением чего-то сложного.
K>Можно конечно в одну кучу собрать и компиляцию и деплой, но по-моему это в итоге неудобно и превращается в кашу.
"Базы знаний" из состояния каши вообще никогда выходят.