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

K>·>Ты же не знаешь как, информации у тебя не было. Он мог собирать у себя на компе в Студии и зиповать бинарики.
K>Ну, теоретически конечно могли Java-проект собирать в студии, а pom.xml с прописанными репозиториями для вида приложить и в сборке не использовать.
Ну в Netbeans, или IDEA или VS code, какая разница-то? Неизвестно же, в любом случае.

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

K>·>Ага-ага. И что ж вы его не удалили, чтоб облегчить себе задачу? Заврался ты, гражданин.
K>Проблемы с чтением или мышлением? Как удаление файла мне облегчило бы задачу, если я пишу, что без него потратил бы минут на 10 больше?
Избавило бы от душевных страданий.

K>·>Не только при желании, но и при возможности, да. Я тебе про settings.xml уже рассказал. Мавен же не ограничивает мир централизованным сценарием. Можно иметь распределённую систему между разными командами, организациями и т.д.
K>Ага. Когда разговор про мавен, то там всё можно и замечательно, когда NuGet позволяет всё то же самое — начинаются кривляния, что якобы там
Не, разговор начался с того, что "сборка [в мавене] привязана к репозиторию и транспорту по сути". Что, мягко говоря, враньё.

K>нужно будет всё делать вручную и вообще всё плохо.
Ну так ведь нужно же всё вручную делать. Выбора-то нет.

K>·>Зачем?
K>Ну, всем же якобы нужны сложные сценарии, которые мышкой не натыкаешь и потому maven замечательный и все в нём разбираются.
K>С этого же наш диалог начался.
Про "_всем_ нужны сложные сценарии" это ты сам придумал, так что спорь с собой.
Впрочем, тут ведь как — в простых сценариях гуи не нужен, IDE может сама добавлять нужные зависимости в процессе набора кода.
А в сложных сценариях гуи бесполезен и даже немножечко вреден, т.к. создаёт чувство ложного комфорта. В сложных случаях нужна автоматизация.

K>·>Ну таких людей много и не надо. Вот Google напрягся и выкатил плагин для docker, и теперь любой мидл это может делать за минуту без баз знаний, Dockerfile, Powershell или Cake или ещё чего.
K>Изучить "нативный" dockerfile — это сложно и нафиг надо.
Не только изучить Dockerfile, но и то каким образом эффективно и корректно запаковать типичное java-приложение в имадж. Чтобы например, слои кешировались, mtime сбрасывался для repeatable сборки, нужные метки и теги ставились из данных проекта.

K>Притащить зависимость от какого-то плагина, в котором нужно разбираться и который наверняка где-то внутри генерирует этот самый dcoekrfile — это круто.
K>Прекрасный подход.
Да, всё верно. Этот плагин написали спецы Гугла, закодировав туда свои знания. Теперь любой джун-миддл может создать имадж за минуты вставив три строчки кода в проект. И это буквально прочитав один параграф текста. Подобный процесс для дотнета будет большая статья с многострочными кусками скриптов, доки докера, установка докера локально, чесание головы чем COPY отличается от ADD, как минимум день старшего дева на смарку и ещё день на написание "базы знаний".

Но если тебе хочется потрахаться или у тебя какие-то нестандартные хотелки, то есть и плагины чтобы с Dockerfile и доками.

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

K>Не вижу проблемы в том, чтобы в проекте на C# разобраться со скриптом сборки, написанном на Cake, который использует синтаксис C# или даже является проектом C# (Frosting).
Т.е. нужно тогда не maven vs msbuild, сравнивать а maven vs вся инфра, требуемая для поддержки проекта.

K>Когда используется maven с плагинами к нему, написанными на Java — это конечно другое и разбираться в этом не нужно, документировать не нужно, всё всем понятно само по себе.
Разобраться на примитивном уровне, конечно, нужно. А документировать что? Оно просто работает.

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

K>·>Ну так и сложные pom.xml тоже редко встречаются.
K>Как же так получилось? Когда для .NET IDE генерируют стандартные csproj без лишних телодвижений со стороны программиста — это ужасный мир винды, где разработчики не умеют правильно работать.
Упрощать простые вещи — это не достижение.

K>Когда в Java нужно самому возиться с xml и получать на выходе точно такой же результат — это замечательный светлый мир.
Не нужно, но можно.

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

K>·>Ты же не знаешь как, информации у тебя не было. Он мог собирать у себя на компе в Студии и зиповать бинарики.
K>Ну, теоретически конечно могли Java-проект собирать в студии, а pom.xml с прописанными репозиториями для вида приложить и в сборке не использовать.
Ну в Netbeans, или IDEA или VS code, какая разница-то? Неизвестно же, в любом случае. Наличие бинарников не означает наличие инфры.

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

K>·>Ага-ага. И что ж вы его не удалили, чтоб облегчить себе задачу? Заврался ты, гражданин.
K>Проблемы с чтением или мышлением? Как удаление файла мне облегчило бы задачу, если я пишу, что без него потратил бы минут на 10 больше?
Избавило бы от душевных страданий.

K>·>Не только при желании, но и при возможности, да. Я тебе про settings.xml уже рассказал. Мавен же не ограничивает мир централизованным сценарием. Можно иметь распределённую систему между разными командами, организациями и т.д.
K>Ага. Когда разговор про мавен, то там всё можно и замечательно, когда NuGet позволяет всё то же самое — начинаются кривляния, что якобы там
Не, разговор начался с того, что "сборка [в мавене] привязана к репозиторию и транспорту по сути". Что, мягко говоря, враньё.

K>нужно будет всё делать вручную и вообще всё плохо.
Ну так ведь нужно же всё вручную делать. Выбора-то нет.

K>·>Зачем?
K>Ну, всем же якобы нужны сложные сценарии, которые мышкой не натыкаешь и потому maven замечательный и все в нём разбираются.
K>С этого же наш диалог начался.
Про "_всем_ нужны сложные сценарии" это ты сам придумал, так что спорь с собой.
Впрочем, тут ведь как — в простых сценариях гуи не нужен, IDE может сама добавлять нужные зависимости в процессе набора кода.
А в сложных сценариях гуи бесполезен и даже немножечко вреден, т.к. создаёт чувство ложного комфорта. В сложных случаях нужна автоматизация.

K>·>Ну таких людей много и не надо. Вот Google напрягся и выкатил плагин для docker, и теперь любой мидл это может делать за минуту без баз знаний, Dockerfile, Powershell или Cake или ещё чего.
K>Изучить "нативный" dockerfile — это сложно и нафиг надо.
Не только изучить Dockerfile, но и то каким образом эффективно и корректно запаковать типичное java-приложение в имадж. Чтобы например, слои кешировались, mtime сбрасывался для repeatable сборки, нужные метки и теги ставились из данных проекта.

K>Притащить зависимость от какого-то плагина, в котором нужно разбираться и который наверняка где-то внутри генерирует этот самый dcoekrfile — это круто.
K>Прекрасный подход.
Да, всё верно. Этот плагин написали спецы Гугла, закодировав туда свои знания. Теперь любой джун-миддл может создать имадж за минуты вставив три строчки кода в проект. И это буквально прочитав один параграф текста. Подобный процесс для дотнета будет большая статья с многострочными кусками скриптов, доки докера, установка докера локально, чесание головы чем COPY отличается от ADD, как минимум день старшего дева на смарку и ещё день на написание "базы знаний".

Но если тебе хочется потрахаться или у тебя какие-то нестандартные хотелки, то есть и плагины чтобы с Dockerfile и доками.

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

K>Не вижу проблемы в том, чтобы в проекте на C# разобраться со скриптом сборки, написанном на Cake, который использует синтаксис C# или даже является проектом C# (Frosting).
Т.е. нужно тогда не maven vs msbuild, сравнивать а maven vs вся инфра, требуемая для поддержки проекта.

K>Когда используется maven с плагинами к нему, написанными на Java — это конечно другое и разбираться в этом не нужно, документировать не нужно, всё всем понятно само по себе.
Разобраться на примитивном уровне, конечно, нужно. А документировать что? Оно просто работает.

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

K>·>Ну так и сложные pom.xml тоже редко встречаются.
K>Как же так получилось? Когда для .NET IDE генерируют стандартные csproj без лишних телодвижений со стороны программиста — это ужасный мир винды, где разработчики не умеют правильно работать.
Упрощать простые вещи — это не достижение.

K>Когда в Java нужно самому возиться с xml и получать на выходе точно такой же результат — это замечательный светлый мир.
Не нужно, но можно.