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

Gt_>в терминах жава подрядчик передал мусор, а не исходники.

Где ознакомиться со всей терминологией жава?

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

S>Для виндового мира запустил проект в студии и запустил. Если, не заработало, значит подрядчик какую то туфту подкинул!
S>А тестировать хоть на линуксе Установка Linux в Windows с помощью WSL
S>Хошь на виндовс.

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

Здравствуйте, 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>Можно конечно в одну кучу собрать и компиляцию и деплой, но по-моему это в итоге неудобно и превращается в кашу.
"Базы знаний" из состояния каши вообще никогда выходят.

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

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

Ну, теоретически конечно могли Java-проект собирать в студии, а pom.xml с прописанными репозиториями для вида приложить и в сборке не использовать.

·>Да, это нормально. А если вы хотите владеть продуктом, то он у вас и должен хоститься. Пусть исполнители пушат в ваш git и у вас всё собирается и деплоится в ваши же репы бинарей.

т.е. внезапно решил переобуться и уже нужно у себя всё собирать, а не получать готовенькое?

·>Ага-ага. И что ж вы его не удалили, чтоб облегчить себе задачу? Заврался ты, гражданин.

Проблемы с чтением или мышлением? Как удаление файла мне облегчило бы задачу, если я пишу, что без него потратил бы минут на 10 больше?

·>Не только при желании, но и при возможности, да. Я тебе про settings.xml уже рассказал. Мавен же не ограничивает мир централизованным сценарием. Можно иметь распределённую систему между разными командами, организациями и т.д.

Ага. Когда разговор про мавен, то там всё можно и замечательно, когда NuGet позволяет всё то же самое — начинаются кривляния, что якобы там нужно будет всё делать вручную и вообще всё плохо.

·>Зачем?

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

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

Изучить "нативный" dockerfile — это сложно и нафиг надо.
Притащить зависимость от какого-то плагина, в котором нужно разбираться и который наверняка где-то внутри генерирует этот самый dcoekrfile — это круто.
Прекрасный подход.

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

Можно и на MSBuild многое наделать. Мне лично неудобно на xml что-то сложное писать.
Не вижу проблемы в том, чтобы в проекте на C# разобраться со скриптом сборки, написанном на Cake, который использует синтаксис C# или даже является проектом C# (Frosting).
Когда используется maven с плагинами к нему, написанными на Java — это конечно другое и разбираться в этом не нужно, документировать не нужно, всё всем понятно само по себе.

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

т.е. на самом maven ничего не делается, а всю работу выполняют сторонние библиотеки.

·>Ну так и сложные pom.xml тоже редко встречаются.

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

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



S>>Для виндового мира запустил проект в студии и запустил. Если, не заработало, значит подрядчик какую то туфту подкинул!
S>>А тестировать хоть на линуксе Установка Linux в Windows с помощью WSL
S>>Хошь на виндовс.

Gt_>я именно об этом, виндовый мир даже не в курсе что такое тесты в жава. соответственно чувак выдумал историю натянув виндовый подход на мир жава. в жава получая исходники запускают тесты.
А, что на винде разве нет тестов в яве?
Для шарпа куча юнит тестов Тестирование в .NET

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

IT>Не знаю. Хотя бы как в Razor, а лучше было сделать свой язык описания GUI. А так получилась полнейшая хрень, многословная, плохо читаемая, с кучей тупых ограничений. К тому же смешит попытка декларативного описания UI, в котором ввели сеттеры специально для декларативного описания императивных операций

Можно было бы на самом C#, но нужно много всего
1. внятные инициализаторы объектов и коллекций, что бы их можно было приклеивать к чему угодно
2. именованые параметры
3. лямбду передавать блоком


Тогда можно как то так:

theComponent1(onClick=onClickHandler) {
    slotA {
        span { text: 'this is a slot' }
    },
    theComponent2() {
        slotB {
            
        }
    },
    slotC {
    }
}

Но похожий синтаксис обрезали задолго до всяких xaml итд. Вобщем, в C# слишком тяжелое наследие Си

Здравствуйте, IT, Вы писали:
IT>>>Ещё более худшей идеей было XAML поверх XML.
A>>А как надо было? Разметку на джейсоне? Или уже смириться, не переизобретать HTML и уйти в монастырь?

IT>Не знаю. Хотя бы как в Razor, а лучше было сделать свой язык описания GUI. А так получилась полнейшая хрень, многословная, плохо читаемая, с кучей тупых ограничений. К тому же смешит попытка декларативного описания UI, в котором ввели сеттеры специально для декларативного описания императивных операций
Меня тоже XAML не особо радует, хотя есть и визуальная часть для редактирования.
Просто за все время ничего нового кроме Xaml так и не придумали. Flutter вообще пишут на Dart, в Котлине свой DSL но опять же HTML
Согласен, что для гуя нужен свой язык максимально декларативный и с визуальной частью.
И это нужно было делать давно.

Здравствуйте, 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>Откуда вот это всё берёшь?
Отсюда: "отдавать заказчику, чтобы он у себя своими билд-серверами всё собрал и развернул".
Софтварная компания передаёт заказчику готовый продукт. Компания передаёт, а не разработчик. А вот разработчик должен выдавать исходники, ясен пень, и отдавать компании-работодателю, но не заказчику.

K>Ты мне начал рассказывать, что разработчики должны разворачивать инфраструктуру у себя, собирать у себя и отдавать всё готовое заказчику.
Это ты врёшь. Или _мою_ цитату в студию.

K>На это я привёл пример из жизни, как одна организация заключила договор с другой организацией на разработку библиотеки.
Это ты так заявил. А на деле оказалось, что одна организация наняла к себе разработчика-контрактника для выполнения работы у себя. Другая организация была просто зонтиком контрактника, а не софтварной конторой.

K>Радостные получали исходники и бинарники. Исходники никто не пытался собирать, а пользовались себе готовыми бинарниками и всё работало.
Школота, чё.

K>Захотели сами что-то поменять — оказалось, что для сборки нужно инфраструктуру разворачивать и допиливать исходники напильником, т.к. в имеющемся состоянии они отказывались компилироваться.
Ага. И не просто "оказалось", а "ВНЕЗАПНО оказалось", что для того чтобы компания могла вести разработку ПО у себя нужно иметь инфраструктуру разработки ПО у себя. Действительно, кто бы мог подумать?!

K>Теперь ты мне рассказываешь, что оказывается надо было сразу у себя инфраструктуру разворачивать и собирать бинарники из исходников у себя (вот так новость).
Угу, прикинь! И, что самое интересное, несмотря на полное долбо**ство, развернуть инфру заняло всего неделю при полном отсуствии специалистов, опыта, баз знаний, документации и прочего. Хватило pom.xml.

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

·>Софтварная компания передаёт заказчику готовый продукт. Компания передаёт, а не разработчик. А вот разработчик должен выдавать исходники, ясен пень, и отдавать компании-работодателю, но не заказчику.

Вы там в ява-мирке все выдумываете какие-то свои определения и термины?
Мне как-то в жизни ни разу ещё ни одна компания ничего не передавала. В глаза даже не видел такое чудо.
Всегда с какими-то сотрудниками контактирую, которые выступают от лица компании.
Где-то это разработчики, где-то менеджеры и т.д.
По каким каналам связи тебе обычно компания что-то передаёт?

·>Это ты врёшь. Или _мою_ цитату в студию.

Такая пойдёт?

https://rsdn.org/forum/dotnet/8642008

Автор: ·
Дата: 27.11.23

Обычно по-другому делается — ты билдишь у себя, а клиентам даёшь доступ к своему репо — он оттуда и тянет всё готовенькое.

·>Это ты так заявил. А на деле оказалось, что одна организация наняла к себе разработчика-контрактника для выполнения работы у себя. Другая организация была просто зонтиком контрактника, а не софтварной конторой.

Ну, тогда любая компания — это "зонтик контрактника", т.к. по сути задачи выполняют какие-то разработчики, а не сама компания.

·>Ага. И не просто "оказалось", а "ВНЕЗАПНО оказалось", что для того чтобы компания могла вести разработку ПО у себя нужно иметь инфраструктуру разработки ПО у себя. Действительно, кто бы мог подумать?!

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

·>Угу, прикинь! И, что самое интересное, несмотря на полное долбо**ство, развернуть инфру заняло всего неделю при полном отсуствии специалистов, опыта, баз знаний, документации и прочего. Хватило pom.xml.

Какой же ты упёртый...

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

K>Какой же ты упёртый...
Не то слово. А сколько при этом времени уходит ...

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

K>·>Софтварная компания передаёт заказчику готовый продукт. Компания передаёт, а не разработчик. А вот разработчик должен выдавать исходники, ясен пень, и отдавать компании-работодателю, но не заказчику.
K>Вы там в ява-мирке все выдумываете какие-то свои определения и термины?
K>Мне как-то в жизни ни разу ещё ни одна компания ничего не передавала. В глаза даже не видел такое чудо.
Microsoft тебе передавала и Newtonsoft и много других. И бинарники, и даже исходники.

K>Всегда с какими-то сотрудниками контактирую, которые выступают от лица компании.
K>Где-то это разработчики, где-то менеджеры и т.д.
K>По каким каналам связи тебе обычно компания что-то передаёт?
Именно, что "от лица компании". А ты мне приписываешь что я якобы от каждого джуна-разработчика лично требую инфраструктуру разворачивать со сложными сценариями сборки.
Ты подменяешь понятия, потом меня обвиняешь во лжи.

K>·>Это ты врёшь. Или _мою_ цитату в студию.
K>Такая пойдёт?
K>

K>https://rsdn.org/forum/dotnet/8642008

Автор: ·
Дата: 27.11.23

K>Обычно по-другому делается — ты билдишь у себя, а клиентам даёшь доступ к своему репо — он оттуда и тянет всё готовенькое.

Смотри строчку выше: это цитата относится к контексту "отдавать заказчику", т.е. когда одна организация передаёт готовый продукт другой. Причём тут разработчик пишуший в исходники?

K>·>Это ты так заявил. А на деле оказалось, что одна организация наняла к себе разработчика-контрактника для выполнения работы у себя. Другая организация была просто зонтиком контрактника, а не софтварной конторой.
K>Ну, тогда любая компания — это "зонтик контрактника", т.к. по сути задачи выполняют какие-то разработчики, а не сама компания.
Исходниками ВНЕЗАПНО (после подписания актов-договоров) захотела владеть ваша компания, а не Microsoft или Newtonsoft или тот зонтик. Ты скажи, ты сколько раз пробовал изменять и пересобирать Newtonsoft.Json и другие либы, прописанные у тебя в депенденсях?

K>·>Ага. И не просто "оказалось", а "ВНЕЗАПНО оказалось", что для того чтобы компания могла вести разработку ПО у себя нужно иметь инфраструктуру разработки ПО у себя. Действительно, кто бы мог подумать?!
K>Ну, так люди работали по твоим рекомендациям, от которых теперь почему-то отнекиваешься.
Каким моим рекомендациям? Что ты опять фантазируешь?

K>·>Угу, прикинь! И, что самое интересное, несмотря на полное долбо**ство, развернуть инфру заняло всего неделю при полном отсуствии специалистов, опыта, баз знаний, документации и прочего. Хватило pom.xml.
K>Какой же ты упёртый...
Это не я упёртый, а факты.

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

K>>Не вижу проблемы в том, чтобы в проекте на C# разобраться со скриптом сборки, написанном на Cake, который использует синтаксис C# или даже является проектом C# (Frosting).
·>Т.е. нужно тогда не maven vs msbuild, сравнивать а maven vs вся инфра, требуемая для поддержки проекта.
Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил.

И смотрим на pom.xml — ровно 200 строк на всё, притом жутко избыточный xml. Весь билд с зависимостями, с доками, с тестами, с подписью, деплойментом, инфой о лицензии, разработчиках, параграф readme и т.п. И заработает в куче разных IDE на куче разных OS.

Вот Gson 528 строк, чуть посложнее, но там кода больше, несколько модулей, перформанс тесты, проверка стиля, обфускация, манипуляция с гит-репой, метрики всякие.

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

·>Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил.

Упустил то, что все эти powershell скрипты не для сборки, а для деплоя.
Мельком пробежал. Там скрипт, который ищет nuget.exe и скачивает его, если не установлен. То же самое для msbuild и т.п.
gradlew вот "зубодробительные скрипты" или всё нормально?
Другие библиотеки на C# посмотреть — там не будет всего этого добра.
Разработчики конкретной библиотеки вот так захотели у себя сделать и что это даёт?

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

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

K>>>Не вижу проблемы в том, чтобы в проекте на C# разобраться со скриптом сборки, написанном на Cake, который использует синтаксис C# или даже является проектом C# (Frosting).
·>·>Т.е. нужно тогда не maven vs msbuild, сравнивать а maven vs вся инфра, требуемая для поддержки проекта.
·>Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил.
Странно ветка про XML, а по ссылке таких файлов нет.
Каждый ... так как хочет. Зато есть возможности.
А вот с граблями я в свое время в Андроид студии намучился. А вот в MS редко были проблемы при переходе с одной версии на другую

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

K>·>Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил.
K>Упустил то, что все эти powershell скрипты не для сборки, а для деплоя.
Не упустил. Суть в том, что pom.xml в 200 строк делает и весь деплой. Иными словами, pom.xml заменяет не только msbuild но и эти портянки скриптов.

K>Мельком пробежал. Там скрипт, который ищет nuget.exe и скачивает его, если не установлен. То же самое для msbuild и т.п.
Именно! И это гно в каждом проекте потребуется.
Ещё интересно, отлаживались ли эти скрипты под разные версии винды, линуха, мака.

K>gradlew вот "зубодробительные скрипты" или всё нормально?
Ну во-первых, он собственно необязателен, нужен только для тех кто предпочитает gradle, притом под винду. Во-вторых, он целиком стандартный автогенерённый файл. Просто коммитят в репу для удобства — после чекаута исходников — сразу запускаешь батник/баш (в зависимости от ОС) и всё работает.
Так что игнорируй этот файл.

K>Другие библиотеки на C# посмотреть — там не будет всего этого добра.
Ок. Посмотрел like-for-like. То же самое, от той же конторы: AWS SDK for Java vs c#. Тут в шарпе гна ещё больше — целый многомодульный под-проект для сборки проекта. С тестами даже! Какая прелесть :

        [Fact]
        public void PassingTest()
        {
            Assert.True(4 == Add(2, 2));
        }

K>Разработчики конкретной библиотеки вот так захотели у себя сделать и что это даёт?
Захотели?! А у них был выбор? Как по-твоему они должны были сделать правильно?

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

S>·>Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил.
S>Странно ветка про XML, а по ссылке таких файлов нет.
Верно. Там такой ужас, что уж лучше бы был XML.

S> Каждый ... так как хочет.
Именно. Стандартный тулчейн просто отсутствует, каждому приходится выкручиваться как "хочет". Добровольно и с песнями (c).

S>А вот с граблями я в свое время в Андроид студии намучился. А вот в MS редко были проблемы при переходе с одной версии на другую
Одно время Андроид Студия была свежая и сырая, ей даже десяти лет нет, да и андроиду самому тоже немного.

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

·>Не упустил. Суть в том, что pom.xml в 200 строк делает и весь деплой. Иными словами, pom.xml заменяет не только msbuild но и эти портянки скриптов.

Какой весь? Он скачает и установит maven? Установит нужную версию JDK? Версию пакета пропишет на основе текущей даты?
Выполнит 8 сборок под разные версии JDK?
Данный pom.xml — примерный аналог файлов csproj от Newtonsoft и не более того.

·>Именно! И это гно в каждом проекте потребуется.

Прямо в любом?
ReactiveUI
FluentFTP
fluentmigrator
ClosedXML
Что-то я не вижу этой кучи скриптов на Powershell.

·>Ещё интересно, отлаживались ли эти скрипты под разные версии винды, линуха, мака.

а должны?

·>Ну во-первых, он собственно необязателен, нужен только для тех кто предпочитает gradle, притом под винду.

Для справки: под винду gradlew.bat, а gradlew — несколько для других ОС.
И по твоей логике выходит, что виндовый cmd круче, т.к. равнозначный батник почти в 2 раза меньше, чем файлик для sh.

·>Во-вторых, он целиком стандартный автогенерённый файл. Просто коммитят в репу для удобства — после чекаута исходников — сразу запускаешь батник/баш (в зависимости от ОС) и всё работает.
·>Так что игнорируй этот файл.

С чего это его игнорировать?
Не видел, чтобы кто-то sln-файлы руками писал, но они почему-то учитывается. csproj тоже обычно IDE сама заполняет и в него особо не заходят.
А build.gradle тоже не нужно учитывать?
А папку .github/workflows?

·>Ок. Посмотрел like-for-like. То же самое, от той же конторы: AWS SDK for Java vs c#. Тут в шарпе гна ещё больше — целый многомодульный под-проект для сборки проекта.

И что? Ну, в AWS так сделали, я тут причём или C# или .NET?

·>С тестами даже! Какая прелесть :

По-моему слова dummy и sample указывают на то, что это какой-то пример, а не реальный тест.
Ну, либо проект делали разработчики с соответствующей квалификацией, что непонятно почему на них ориентироваться нужно.
Раз ты считаешь, что они написали смешную чушь, то почему ставишь в пример?

·>Захотели?! А у них был выбор? Как по-твоему они должны были сделать правильно?

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

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

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

S>>·>Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил.
S>>Странно ветка про XML, а по ссылке таких файлов нет.
·>Верно. Там такой ужас, что уж лучше бы был XML.
Мне глубоко наплевать на формат. Мне нужна визуальная часть и классы для чтения и записи. Вручную не люблю.
В той же студии для сборки полно событий до и после сборки.

S>> Каждый ... так как хочет.
·>Именно. Стандартный тулчейн просто отсутствует, каждому приходится выкручиваться как "хочет". Добровольно и с песнями (c).
Стандартный как раз присутствует. Просто они сами заморачиваются. Все есть и можно многое прописывать в настройках.

S>>А вот с граблями я в свое время в Андроид студии намучился. А вот в MS редко были проблемы при переходе с одной версии на другую
·>Одно время Андроид Студия была свежая и сырая, ей даже десяти лет нет, да и андроиду самому тоже немного.

Андроиду больше чем .Net Core, однако есть все для отладки на разных платформах итд.