Сообщение Re[38]: msbuild поверх xml - была плохая идея? от 01.12.2023 11:13
Изменено 01.12.2023 11:17 ·
Re[38]: msbuild поверх xml - была плохая идея?
Здравствуйте, karbofos42, Вы писали:
K>·>Конечно, не бином ньютона. https://maven.apache.org/wrapper/ но обычно нафиг не надо, и в этом проекте не добавлен.
K>·>И для gradle вот тот самый gradew — самоскачивальщик и есть.
K>Так и nuget обычно никому не нужно скачивать и другие разработчики почему-то этим не занимаются, но ты распереживался из-за наличия скрипта для этого в конкретной библиотеке.
Ты врёшь. Скрипт не только это делает. Он там много что делает — скачивает не что-то одно, а несколько вещей, потом тулзы в определённом порядке вызывает.
Вот тут по-твоему что? https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1#L48-L165 плюс L267-L329 Даже что-то с XML шаманят
K>·>maven-compiler-plugin <target>
K>Убрал на компе переменную окружения JAVA_HOME, в pom.xml прописал:
Анекдот №10056243
K>Всё же нужно оказывается окружение для сборки предварительно настраивать.
Не очень понял. А для разработки на дотнете фреймворк не обязателен?
В случае mvnw или gradlew нужно только jdk (идёт в поставке с каждой ide для java ну или "apt install" и т.п.). Дальше всё само разворачивается. А у тебя там в скрипте куча чего скачивается и куча шагов выполняется.
K>·>Да, но так не надо делать, конечно. Лучше из тега гита выковыривать или из номера билда на соответствующем CI-сервере.
K>т.е. нужно гвоздями прибивать к конкретной CI?
Нет, не нужно.
K>·>Это зачем? Есть такая штука, backward compatibility называется.
K>Затем, что Newtonsoft.Json собирается и под старые рантаймы, где ещё не было асинхронного программирования и т.п.
Ну там тоже что-то есть для jdk1.6. Не знаю накой всё ещё держат... наверное удалять просто лень.
K>Другие библиотеки используют для оптимизации, например, Span, которые не так давно появились.
K>Если ориентироваться под минимальную версию, то не получится задействовать плюшки и оптимизации, доступные в новых версиях.
K>Если ориентироваться на последние версии, то без библиотеки останутся разработчики под старые фреймворки.
Если такое действительно надо, просто добавляют два pom-модуля с разными <target>.
K>А вот это я так понимаю пример backward compatibility https://github.com/google/gson/issues/2501 ?
Нет. Это forward compatibility.
Собранная либа на jdk8 будет работать и в jdk21 — это backward compatibility.
K>·>Нет. Ты можешь склонировать проект и запустить полный цикл у себя. Что-нибудь пропатчить, а потом компиляция, тесты, деплоймент, возможно себе локально или внутри своей конторы.
K>И откуда возьмётся деплоймент?
Из mvn deploy.
K>Может всё же мне придётся брать свою CI, прикручивать к ней вызов какого-нибудь mvn deploy, а в pom.xml переписывать адреса,
Можно, но не обязательно. Просто из командной строки "mvn deploy -DaltDeploymentRepository=myCoolRepo..." ну или просто поставить через "mvn install" себе локально, для экспериментов, например.
K>а рядом ещё класть какой-нибудь ci_settings.xml для добавления DEPLOY_TOKEN ?
Поскандалить изволите или так, от чистого сердца? Секреты и пароли, ясен пень надо предъявлять отдельно. На то они и токены-пароли.
K>Аналог этой папочки Build в итоге и нужно будет сделать, если захочется такого же деплоймента, который в Newtonsoft.Json сделан
Нет. Как видно по исходникам — не нужно.
K>·>Ну да, а ты думал в сказку попал? И каждый выкручивается как может.
K>Деплоймент всегда делается и должен работать на конкретной инфраструктуре.
Молодцы в Майкрософте. Промыть мозги, что б не дай бог, чего б лишнего не захотели. Главное юзеров в узде держать, EEE. Иначе деньги не за что грести будет.
K>Мне вот нужен деплоймент, который сработает изолированно в интранете без всех этих интернетов. И что мне даст gradlew?
Ты должен будешь разместить где-то в этом своём интранете требуемые бинарники. Обычно просто прокси-зеркало делают. Примерно как если ты захочешь в интранете иметь публичные nuget-либы.
K>>>ReactiveUI
K>·>Тут гвоздями к github.com прибито: https://github.com/reactiveui/actions-common/blob/main/.github/workflows/workflow-common-setup-and-build.yml и далее по ссылкам, там такая колбаса...
K>·>Скачать исходники к себе и побилдить/подеплоить в свою инфру — надо будет с бубном танцевать.
K>Для скачать и побилдить эта папка не нужна,
Какой одной командой запустить весь цикл до деплоя? Компиляция, тесты, сборка, верификация, документация, локальная инсталляция?
K>а для деплоя через CI всё равно похожий yml будешь писать, который будет дёргать mvn deploy.
K>Не вижу что-то переживаний из-за папки: https://github.com/stleary/JSON-java/tree/master/.github/workflows
Потому что это описание джобы конкретного CI-сервера. Из кода там ровно одна строка. На других серверах/локально будешь просто запускать ту же строку передавая информацию о своей конкретной инфраструктуре.
K>·>Вот какая-то фигня https://github.com/robinrodricks/FluentFTP/blob/master/FluentFTP.Dockers/Build.bat
K>Это для тестов собираются docker-контейнеры для разных FTP-серверов, т.к. протокол сильно произвольный и у каждого сервера своё его видение.
K>Будешь рассказывать, что это всё не нужно делать и pom.xml в 3 строчки подготовит десяток контейнеров?
Эээ. Ну да, а что? Ок, не 3 строчки на всё, но по 3 строчки на контейнер — да. integration-test and verify phases.
K>·>А кроме билда тут вообще ничего нет, ни подписи, ни деплоймента, ни всякого покрытия/анализа когда. Это всё где-то в инфре вендора.
K>так и в pom.xml нет деплоймента
Т.к. в pom.xml нет паролей и приватных ключей, то будем писать километровые батники, чтобы тесты запустить.
K>Я вот скачал твою библиотеку для json, выполняю mvn deploy и получаю:
K>
K>А если установлю себе gpg, то окажется, что сертификата для подписи нет, а потом что я не смогу задеплоить в прописанный репозиторий?
K>Или мне разрешат таки понаписать что попало и задеплоить кривую библиотеку в официальные репозитории?
Ты правда не понимаешь что такое подпись? Что ты тупо не имеешь права подписывать?
Если ты хочешь подеплоить у себя дома для своих друзей, то ты должен использовать свой личный приватный ключ. А если у тебя есть ключ, то тебя должен быть и gpg. Ну или можешь скипнуть шаг подписи "mvn deploy -Dgpg.skip".
K>·>Тут к азуру приколочено.
K>ну, твой pom.xml тоже приколочен же к конкретному репозиторию и умеет только с ним работать
Нет.
K>·>Appveyor какой-то.
K>Это CI, которого я не вижу в pom.xml
Нет.
K>·>Разберись, блин.
K>С чем?
Я тебе ссылку на доку давал. Может ты поанглиццки читать не умеешь?
K>gradlew и gradlew.bat делают одно и то же?
Да. gradlew — это bash для линухов, gradelw.bat — то же для виндов.
K>В gradlew.bat меньше строк?
K>Ну, значит он лучше.
Дядя Петя?
K>·>Потому что это не исходник. Майнтенанс нулевой. И контент идентичный во всём мире. Часть gradle, а не проекта.
K>Он лежит в проекте, значит часть проекта. Завтра в нём обнаружат ошибку/уязвимость и будешь во все свои проекты вносить изменения.
Нет.
K>·>Это привязка к гитхабу. Но проект можно скачать к себе и полноценно использовать у себя без всякого гитхаба.
K>·>Там единственная команда по сути "mvn --batch-mode deploy" — остальное обвязка для паролей-секретов. И собственно всё. В другой инфре это будет другим, ясен пень.
K>т.е. когда в проектах на .NET ровно так же ровно с этой папкой, то это прибито гвоздями, а тут внезапно всё хорошо
Да.
K>·>Как пример что приходится делать.
K>Я ни разу такого не делал почему-то.
Потому что ты не делал переиспользуемые другими компоненты-библиотеки, скорее всего.
K>·>Разберись. Это тест системы тестирования билда.
K>т.е. разработчики идиоты, что делают такие тесты?
А у них есть выбор не делать? Вот ты такой неидиот — закинь им PR, удали им ту папочку и объясни им как это всё сделать кликнув пару тикбоксов в Студии.
K>·>А какой у них был выбор? Какие у них были другие средства и почему они оказались менее удобными?
K>В CI дёргаешь сборку из образа docker, где заведомо есть нужный dotnet и не потребуются скрипты скачивания nuget, msbuild и т.п.
И где это взять готовое и засунуть в мой новый проект? Да ещё и докер локально ставить-настраивать?!
K>В итоге будет небольшой yml, который просто будет dotnet вызывать, как это делают в CI, вызывая mvn deploy
Почему этот небольшой yml ещё никто не написал и не выложил публично?
K>·>Чтобы что?
K>Чтобы в проекте не было лишнего, а деплой был отдельно от сборки.
Чтобы что?
K>А зачем смешивать сборку и деплой в pom.xml, а потом ещё половину деплоя отдельно в CI реализовывать?
Между сборкой и деплоем ты пропустил ещё несколько шагов.
K>Чтобы всё друг к другу гвоздями прибито было?
Не знаю, чтоб всё как ты любишь.
K>·>Конечно, не бином ньютона. https://maven.apache.org/wrapper/ но обычно нафиг не надо, и в этом проекте не добавлен.
K>·>И для gradle вот тот самый gradew — самоскачивальщик и есть.
K>Так и nuget обычно никому не нужно скачивать и другие разработчики почему-то этим не занимаются, но ты распереживался из-за наличия скрипта для этого в конкретной библиотеке.
Ты врёшь. Скрипт не только это делает. Он там много что делает — скачивает не что-то одно, а несколько вещей, потом тулзы в определённом порядке вызывает.
Вот тут по-твоему что? https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1#L48-L165 плюс L267-L329 Даже что-то с XML шаманят
K>·>maven-compiler-plugin <target>
K>Убрал на компе переменную окружения JAVA_HOME, в pom.xml прописал:
Анекдот №10056243
K>Всё же нужно оказывается окружение для сборки предварительно настраивать.
Не очень понял. А для разработки на дотнете фреймворк не обязателен?
В случае mvnw или gradlew нужно только jdk (идёт в поставке с каждой ide для java ну или "apt install" и т.п.). Дальше всё само разворачивается. А у тебя там в скрипте куча чего скачивается и куча шагов выполняется.
K>·>Да, но так не надо делать, конечно. Лучше из тега гита выковыривать или из номера билда на соответствующем CI-сервере.
K>т.е. нужно гвоздями прибивать к конкретной CI?
Нет, не нужно.
K>·>Это зачем? Есть такая штука, backward compatibility называется.
K>Затем, что Newtonsoft.Json собирается и под старые рантаймы, где ещё не было асинхронного программирования и т.п.
Ну там тоже что-то есть для jdk1.6. Не знаю накой всё ещё держат... наверное удалять просто лень.
K>Другие библиотеки используют для оптимизации, например, Span, которые не так давно появились.
K>Если ориентироваться под минимальную версию, то не получится задействовать плюшки и оптимизации, доступные в новых версиях.
K>Если ориентироваться на последние версии, то без библиотеки останутся разработчики под старые фреймворки.
Если такое действительно надо, просто добавляют два pom-модуля с разными <target>.
K>А вот это я так понимаю пример backward compatibility https://github.com/google/gson/issues/2501 ?
Нет. Это forward compatibility.
Собранная либа на jdk8 будет работать и в jdk21 — это backward compatibility.
K>·>Нет. Ты можешь склонировать проект и запустить полный цикл у себя. Что-нибудь пропатчить, а потом компиляция, тесты, деплоймент, возможно себе локально или внутри своей конторы.
K>И откуда возьмётся деплоймент?
Из mvn deploy.
K>Может всё же мне придётся брать свою CI, прикручивать к ней вызов какого-нибудь mvn deploy, а в pom.xml переписывать адреса,
Можно, но не обязательно. Просто из командной строки "mvn deploy -DaltDeploymentRepository=myCoolRepo..." ну или просто поставить через "mvn install" себе локально, для экспериментов, например.
K>а рядом ещё класть какой-нибудь ci_settings.xml для добавления DEPLOY_TOKEN ?
Поскандалить изволите или так, от чистого сердца? Секреты и пароли, ясен пень надо предъявлять отдельно. На то они и токены-пароли.
K>Аналог этой папочки Build в итоге и нужно будет сделать, если захочется такого же деплоймента, который в Newtonsoft.Json сделан
Нет. Как видно по исходникам — не нужно.
K>·>Ну да, а ты думал в сказку попал? И каждый выкручивается как может.
K>Деплоймент всегда делается и должен работать на конкретной инфраструктуре.
Молодцы в Майкрософте. Промыть мозги, что б не дай бог, чего б лишнего не захотели. Главное юзеров в узде держать, EEE. Иначе деньги не за что грести будет.
K>Мне вот нужен деплоймент, который сработает изолированно в интранете без всех этих интернетов. И что мне даст gradlew?
Ты должен будешь разместить где-то в этом своём интранете требуемые бинарники. Обычно просто прокси-зеркало делают. Примерно как если ты захочешь в интранете иметь публичные nuget-либы.
K>>>ReactiveUI
K>·>Тут гвоздями к github.com прибито: https://github.com/reactiveui/actions-common/blob/main/.github/workflows/workflow-common-setup-and-build.yml и далее по ссылкам, там такая колбаса...
K>·>Скачать исходники к себе и побилдить/подеплоить в свою инфру — надо будет с бубном танцевать.
K>Для скачать и побилдить эта папка не нужна,
Какой одной командой запустить весь цикл до деплоя? Компиляция, тесты, сборка, верификация, документация, локальная инсталляция?
K>а для деплоя через CI всё равно похожий yml будешь писать, который будет дёргать mvn deploy.
K>Не вижу что-то переживаний из-за папки: https://github.com/stleary/JSON-java/tree/master/.github/workflows
Потому что это описание джобы конкретного CI-сервера. Из кода там ровно одна строка. На других серверах/локально будешь просто запускать ту же строку передавая информацию о своей конкретной инфраструктуре.
K>·>Вот какая-то фигня https://github.com/robinrodricks/FluentFTP/blob/master/FluentFTP.Dockers/Build.bat
K>Это для тестов собираются docker-контейнеры для разных FTP-серверов, т.к. протокол сильно произвольный и у каждого сервера своё его видение.
K>Будешь рассказывать, что это всё не нужно делать и pom.xml в 3 строчки подготовит десяток контейнеров?
Эээ. Ну да, а что? Ок, не 3 строчки на всё, но по 3 строчки на контейнер — да. integration-test and verify phases.
K>·>А кроме билда тут вообще ничего нет, ни подписи, ни деплоймента, ни всякого покрытия/анализа когда. Это всё где-то в инфре вендора.
K>так и в pom.xml нет деплоймента
Т.к. в pom.xml нет паролей и приватных ключей, то будем писать километровые батники, чтобы тесты запустить.
K>Я вот скачал твою библиотеку для json, выполняю mvn deploy и получаю:
K>
K>А как так получилось? Всё ведь работает из коробки, нужно просто скачать?K>[ERROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.6:sign (sign-artifacts) on project json: Unable to execute gpg command: Error while executing process. Cannot
K>run program "gpg.exe": CreateProcess error=2, Не удается найти указанный файл -> [Help 1]
K>А если установлю себе gpg, то окажется, что сертификата для подписи нет, а потом что я не смогу задеплоить в прописанный репозиторий?
K>Или мне разрешат таки понаписать что попало и задеплоить кривую библиотеку в официальные репозитории?
Ты правда не понимаешь что такое подпись? Что ты тупо не имеешь права подписывать?
Если ты хочешь подеплоить у себя дома для своих друзей, то ты должен использовать свой личный приватный ключ. А если у тебя есть ключ, то тебя должен быть и gpg. Ну или можешь скипнуть шаг подписи "mvn deploy -Dgpg.skip".
K>·>Тут к азуру приколочено.
K>ну, твой pom.xml тоже приколочен же к конкретному репозиторию и умеет только с ним работать
Нет.
K>·>Appveyor какой-то.
K>Это CI, которого я не вижу в pom.xml
Нет.
K>·>Разберись, блин.
K>С чем?
Я тебе ссылку на доку давал. Может ты поанглиццки читать не умеешь?
K>gradlew и gradlew.bat делают одно и то же?
Да. gradlew — это bash для линухов, gradelw.bat — то же для виндов.
K>В gradlew.bat меньше строк?
K>Ну, значит он лучше.
Дядя Петя?
K>·>Потому что это не исходник. Майнтенанс нулевой. И контент идентичный во всём мире. Часть gradle, а не проекта.
K>Он лежит в проекте, значит часть проекта. Завтра в нём обнаружат ошибку/уязвимость и будешь во все свои проекты вносить изменения.
Нет.
K>·>Это привязка к гитхабу. Но проект можно скачать к себе и полноценно использовать у себя без всякого гитхаба.
K>·>Там единственная команда по сути "mvn --batch-mode deploy" — остальное обвязка для паролей-секретов. И собственно всё. В другой инфре это будет другим, ясен пень.
K>т.е. когда в проектах на .NET ровно так же ровно с этой папкой, то это прибито гвоздями, а тут внезапно всё хорошо
Да.
K>·>Как пример что приходится делать.
K>Я ни разу такого не делал почему-то.
Потому что ты не делал переиспользуемые другими компоненты-библиотеки, скорее всего.
K>·>Разберись. Это тест системы тестирования билда.
K>т.е. разработчики идиоты, что делают такие тесты?
А у них есть выбор не делать? Вот ты такой неидиот — закинь им PR, удали им ту папочку и объясни им как это всё сделать кликнув пару тикбоксов в Студии.
K>·>А какой у них был выбор? Какие у них были другие средства и почему они оказались менее удобными?
K>В CI дёргаешь сборку из образа docker, где заведомо есть нужный dotnet и не потребуются скрипты скачивания nuget, msbuild и т.п.
И где это взять готовое и засунуть в мой новый проект? Да ещё и докер локально ставить-настраивать?!
K>В итоге будет небольшой yml, который просто будет dotnet вызывать, как это делают в CI, вызывая mvn deploy
Почему этот небольшой yml ещё никто не написал и не выложил публично?
K>·>Чтобы что?
K>Чтобы в проекте не было лишнего, а деплой был отдельно от сборки.
Чтобы что?
K>А зачем смешивать сборку и деплой в pom.xml, а потом ещё половину деплоя отдельно в CI реализовывать?
Между сборкой и деплоем ты пропустил ещё несколько шагов.
K>Чтобы всё друг к другу гвоздями прибито было?
Не знаю, чтоб всё как ты любишь.
Re[38]: msbuild поверх xml - была плохая идея?
Здравствуйте, karbofos42, Вы писали:
K>·>Конечно, не бином ньютона. https://maven.apache.org/wrapper/ но обычно нафиг не надо, и в этом проекте не добавлен.
K>·>И для gradle вот тот самый gradew — самоскачивальщик и есть.
K>Так и nuget обычно никому не нужно скачивать и другие разработчики почему-то этим не занимаются, но ты распереживался из-за наличия скрипта для этого в конкретной библиотеке.
Ты врёшь. Скрипт не только это делает. Он там много что делает — скачивает не что-то одно, а несколько вещей, потом тулзы в определённом порядке вызывает.
Вот тут по-твоему что? https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1#L48-L165 плюс L267-L329 Даже что-то с XML шаманят
K>·>maven-compiler-plugin <target>
K>Убрал на компе переменную окружения JAVA_HOME, в pom.xml прописал:
Анекдот №10056243
K>Всё же нужно оказывается окружение для сборки предварительно настраивать.
Не очень понял. А для разработки на дотнете фреймворк не обязателен?
В случае mvnw или gradlew нужно только jdk (идёт в поставке с каждой ide для java ну или "apt install" и т.п.). Дальше всё само разворачивается. А у тебя там в скрипте куча чего скачивается и куча шагов выполняется.
K>·>Да, но так не надо делать, конечно. Лучше из тега гита выковыривать или из номера билда на соответствующем CI-сервере.
K>т.е. нужно гвоздями прибивать к конкретной CI?
Нет, не нужно.
K>·>Это зачем? Есть такая штука, backward compatibility называется.
K>Затем, что Newtonsoft.Json собирается и под старые рантаймы, где ещё не было асинхронного программирования и т.п.
Ну там тоже что-то есть для jdk1.6, который был deprecated ещё до выхода Core. Не знаю накой всё ещё держат... наверное удалять просто лень.
K>Другие библиотеки используют для оптимизации, например, Span, которые не так давно появились.
K>Если ориентироваться под минимальную версию, то не получится задействовать плюшки и оптимизации, доступные в новых версиях.
K>Если ориентироваться на последние версии, то без библиотеки останутся разработчики под старые фреймворки.
Если такое действительно надо, просто добавляют два pom-модуля с разными <target>.
K>А вот это я так понимаю пример backward compatibility https://github.com/google/gson/issues/2501 ?
Нет. Это forward compatibility.
Собранная либа на jdk8 будет работать и в jdk21 — это backward compatibility.
K>·>Нет. Ты можешь склонировать проект и запустить полный цикл у себя. Что-нибудь пропатчить, а потом компиляция, тесты, деплоймент, возможно себе локально или внутри своей конторы.
K>И откуда возьмётся деплоймент?
Из mvn deploy.
K>Может всё же мне придётся брать свою CI, прикручивать к ней вызов какого-нибудь mvn deploy, а в pom.xml переписывать адреса,
Можно, но не обязательно. Просто из командной строки "mvn deploy -DaltDeploymentRepository=myCoolRepo..." ну или просто поставить через "mvn install" себе локально, для экспериментов, например.
K>а рядом ещё класть какой-нибудь ci_settings.xml для добавления DEPLOY_TOKEN ?
Поскандалить изволите или так, от чистого сердца? Секреты и пароли, ясен пень надо предъявлять отдельно. На то они и токены-пароли.
K>Аналог этой папочки Build в итоге и нужно будет сделать, если захочется такого же деплоймента, который в Newtonsoft.Json сделан
Нет. Как видно по исходникам — не нужно.
K>·>Ну да, а ты думал в сказку попал? И каждый выкручивается как может.
K>Деплоймент всегда делается и должен работать на конкретной инфраструктуре.
Молодцы в Майкрософте. Промыть мозги, что б не дай бог, чего б лишнего не захотели. Главное юзеров в узде держать, EEE. Иначе деньги не за что грести будет.
K>Мне вот нужен деплоймент, который сработает изолированно в интранете без всех этих интернетов. И что мне даст gradlew?
Ты должен будешь разместить где-то в этом своём интранете требуемые бинарники. Обычно просто прокси-зеркало делают. Примерно как если ты захочешь в интранете иметь публичные nuget-либы.
K>>>ReactiveUI
K>·>Тут гвоздями к github.com прибито: https://github.com/reactiveui/actions-common/blob/main/.github/workflows/workflow-common-setup-and-build.yml и далее по ссылкам, там такая колбаса...
K>·>Скачать исходники к себе и побилдить/подеплоить в свою инфру — надо будет с бубном танцевать.
K>Для скачать и побилдить эта папка не нужна,
Какой одной командой запустить весь цикл до деплоя? Компиляция, тесты, сборка, верификация, документация, локальная инсталляция?
K>а для деплоя через CI всё равно похожий yml будешь писать, который будет дёргать mvn deploy.
K>Не вижу что-то переживаний из-за папки: https://github.com/stleary/JSON-java/tree/master/.github/workflows
Потому что это описание джобы конкретного CI-сервера. Из кода там ровно одна строка. На других серверах/локально будешь просто запускать ту же строку передавая информацию о своей конкретной инфраструктуре.
K>·>Вот какая-то фигня https://github.com/robinrodricks/FluentFTP/blob/master/FluentFTP.Dockers/Build.bat
K>Это для тестов собираются docker-контейнеры для разных FTP-серверов, т.к. протокол сильно произвольный и у каждого сервера своё его видение.
K>Будешь рассказывать, что это всё не нужно делать и pom.xml в 3 строчки подготовит десяток контейнеров?
Эээ. Ну да, а что? Ок, не 3 строчки на всё, но по 3 строчки на контейнер — да. integration-test and verify phases.
K>·>А кроме билда тут вообще ничего нет, ни подписи, ни деплоймента, ни всякого покрытия/анализа когда. Это всё где-то в инфре вендора.
K>так и в pom.xml нет деплоймента
Т.к. в pom.xml нет паролей и приватных ключей, то будем писать километровые батники, чтобы тесты запустить.
K>Я вот скачал твою библиотеку для json, выполняю mvn deploy и получаю:
K>
K>А если установлю себе gpg, то окажется, что сертификата для подписи нет, а потом что я не смогу задеплоить в прописанный репозиторий?
K>Или мне разрешат таки понаписать что попало и задеплоить кривую библиотеку в официальные репозитории?
Ты правда не понимаешь что такое подпись? Что ты тупо не имеешь права подписывать?
Если ты хочешь подеплоить у себя дома для своих друзей, то ты должен использовать свой личный приватный ключ. А если у тебя есть ключ, то тебя должен быть и gpg. Ну или можешь скипнуть шаг подписи "mvn deploy -Dgpg.skip".
K>·>Тут к азуру приколочено.
K>ну, твой pom.xml тоже приколочен же к конкретному репозиторию и умеет только с ним работать
Нет.
K>·>Appveyor какой-то.
K>Это CI, которого я не вижу в pom.xml
Нет.
K>·>Разберись, блин.
K>С чем?
Я тебе ссылку на доку давал. Может ты поанглиццки читать не умеешь?
K>gradlew и gradlew.bat делают одно и то же?
Да. gradlew — это bash для линухов, gradelw.bat — то же для виндов.
K>В gradlew.bat меньше строк?
K>Ну, значит он лучше.
Дядя Петя?
K>·>Потому что это не исходник. Майнтенанс нулевой. И контент идентичный во всём мире. Часть gradle, а не проекта.
K>Он лежит в проекте, значит часть проекта. Завтра в нём обнаружат ошибку/уязвимость и будешь во все свои проекты вносить изменения.
Нет.
K>·>Это привязка к гитхабу. Но проект можно скачать к себе и полноценно использовать у себя без всякого гитхаба.
K>·>Там единственная команда по сути "mvn --batch-mode deploy" — остальное обвязка для паролей-секретов. И собственно всё. В другой инфре это будет другим, ясен пень.
K>т.е. когда в проектах на .NET ровно так же ровно с этой папкой, то это прибито гвоздями, а тут внезапно всё хорошо
Да.
K>·>Как пример что приходится делать.
K>Я ни разу такого не делал почему-то.
Потому что ты не делал переиспользуемые другими компоненты-библиотеки, скорее всего.
K>·>Разберись. Это тест системы тестирования билда.
K>т.е. разработчики идиоты, что делают такие тесты?
А у них есть выбор не делать? Вот ты такой неидиот — закинь им PR, удали им ту папочку и объясни им как это всё сделать кликнув пару тикбоксов в Студии.
K>·>А какой у них был выбор? Какие у них были другие средства и почему они оказались менее удобными?
K>В CI дёргаешь сборку из образа docker, где заведомо есть нужный dotnet и не потребуются скрипты скачивания nuget, msbuild и т.п.
И где это взять готовое и засунуть в мой новый проект? Да ещё и докер локально ставить-настраивать?!
K>В итоге будет небольшой yml, который просто будет dotnet вызывать, как это делают в CI, вызывая mvn deploy
Почему этот небольшой yml ещё никто не написал и не выложил публично?
K>·>Чтобы что?
K>Чтобы в проекте не было лишнего, а деплой был отдельно от сборки.
Чтобы что?
K>А зачем смешивать сборку и деплой в pom.xml, а потом ещё половину деплоя отдельно в CI реализовывать?
Между сборкой и деплоем ты пропустил ещё несколько шагов.
K>Чтобы всё друг к другу гвоздями прибито было?
Не знаю, чтоб всё как ты любишь.
K>·>Конечно, не бином ньютона. https://maven.apache.org/wrapper/ но обычно нафиг не надо, и в этом проекте не добавлен.
K>·>И для gradle вот тот самый gradew — самоскачивальщик и есть.
K>Так и nuget обычно никому не нужно скачивать и другие разработчики почему-то этим не занимаются, но ты распереживался из-за наличия скрипта для этого в конкретной библиотеке.
Ты врёшь. Скрипт не только это делает. Он там много что делает — скачивает не что-то одно, а несколько вещей, потом тулзы в определённом порядке вызывает.
Вот тут по-твоему что? https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1#L48-L165 плюс L267-L329 Даже что-то с XML шаманят
K>·>maven-compiler-plugin <target>
K>Убрал на компе переменную окружения JAVA_HOME, в pom.xml прописал:
Анекдот №10056243
K>Всё же нужно оказывается окружение для сборки предварительно настраивать.
Не очень понял. А для разработки на дотнете фреймворк не обязателен?
В случае mvnw или gradlew нужно только jdk (идёт в поставке с каждой ide для java ну или "apt install" и т.п.). Дальше всё само разворачивается. А у тебя там в скрипте куча чего скачивается и куча шагов выполняется.
K>·>Да, но так не надо делать, конечно. Лучше из тега гита выковыривать или из номера билда на соответствующем CI-сервере.
K>т.е. нужно гвоздями прибивать к конкретной CI?
Нет, не нужно.
K>·>Это зачем? Есть такая штука, backward compatibility называется.
K>Затем, что Newtonsoft.Json собирается и под старые рантаймы, где ещё не было асинхронного программирования и т.п.
Ну там тоже что-то есть для jdk1.6, который был deprecated ещё до выхода Core. Не знаю накой всё ещё держат... наверное удалять просто лень.
K>Другие библиотеки используют для оптимизации, например, Span, которые не так давно появились.
K>Если ориентироваться под минимальную версию, то не получится задействовать плюшки и оптимизации, доступные в новых версиях.
K>Если ориентироваться на последние версии, то без библиотеки останутся разработчики под старые фреймворки.
Если такое действительно надо, просто добавляют два pom-модуля с разными <target>.
K>А вот это я так понимаю пример backward compatibility https://github.com/google/gson/issues/2501 ?
Нет. Это forward compatibility.
Собранная либа на jdk8 будет работать и в jdk21 — это backward compatibility.
K>·>Нет. Ты можешь склонировать проект и запустить полный цикл у себя. Что-нибудь пропатчить, а потом компиляция, тесты, деплоймент, возможно себе локально или внутри своей конторы.
K>И откуда возьмётся деплоймент?
Из mvn deploy.
K>Может всё же мне придётся брать свою CI, прикручивать к ней вызов какого-нибудь mvn deploy, а в pom.xml переписывать адреса,
Можно, но не обязательно. Просто из командной строки "mvn deploy -DaltDeploymentRepository=myCoolRepo..." ну или просто поставить через "mvn install" себе локально, для экспериментов, например.
K>а рядом ещё класть какой-нибудь ci_settings.xml для добавления DEPLOY_TOKEN ?
Поскандалить изволите или так, от чистого сердца? Секреты и пароли, ясен пень надо предъявлять отдельно. На то они и токены-пароли.
K>Аналог этой папочки Build в итоге и нужно будет сделать, если захочется такого же деплоймента, который в Newtonsoft.Json сделан
Нет. Как видно по исходникам — не нужно.
K>·>Ну да, а ты думал в сказку попал? И каждый выкручивается как может.
K>Деплоймент всегда делается и должен работать на конкретной инфраструктуре.
Молодцы в Майкрософте. Промыть мозги, что б не дай бог, чего б лишнего не захотели. Главное юзеров в узде держать, EEE. Иначе деньги не за что грести будет.
K>Мне вот нужен деплоймент, который сработает изолированно в интранете без всех этих интернетов. И что мне даст gradlew?
Ты должен будешь разместить где-то в этом своём интранете требуемые бинарники. Обычно просто прокси-зеркало делают. Примерно как если ты захочешь в интранете иметь публичные nuget-либы.
K>>>ReactiveUI
K>·>Тут гвоздями к github.com прибито: https://github.com/reactiveui/actions-common/blob/main/.github/workflows/workflow-common-setup-and-build.yml и далее по ссылкам, там такая колбаса...
K>·>Скачать исходники к себе и побилдить/подеплоить в свою инфру — надо будет с бубном танцевать.
K>Для скачать и побилдить эта папка не нужна,
Какой одной командой запустить весь цикл до деплоя? Компиляция, тесты, сборка, верификация, документация, локальная инсталляция?
K>а для деплоя через CI всё равно похожий yml будешь писать, который будет дёргать mvn deploy.
K>Не вижу что-то переживаний из-за папки: https://github.com/stleary/JSON-java/tree/master/.github/workflows
Потому что это описание джобы конкретного CI-сервера. Из кода там ровно одна строка. На других серверах/локально будешь просто запускать ту же строку передавая информацию о своей конкретной инфраструктуре.
K>·>Вот какая-то фигня https://github.com/robinrodricks/FluentFTP/blob/master/FluentFTP.Dockers/Build.bat
K>Это для тестов собираются docker-контейнеры для разных FTP-серверов, т.к. протокол сильно произвольный и у каждого сервера своё его видение.
K>Будешь рассказывать, что это всё не нужно делать и pom.xml в 3 строчки подготовит десяток контейнеров?
Эээ. Ну да, а что? Ок, не 3 строчки на всё, но по 3 строчки на контейнер — да. integration-test and verify phases.
K>·>А кроме билда тут вообще ничего нет, ни подписи, ни деплоймента, ни всякого покрытия/анализа когда. Это всё где-то в инфре вендора.
K>так и в pom.xml нет деплоймента
Т.к. в pom.xml нет паролей и приватных ключей, то будем писать километровые батники, чтобы тесты запустить.
K>Я вот скачал твою библиотеку для json, выполняю mvn deploy и получаю:
K>
K>А как так получилось? Всё ведь работает из коробки, нужно просто скачать?K>[ERROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.6:sign (sign-artifacts) on project json: Unable to execute gpg command: Error while executing process. Cannot
K>run program "gpg.exe": CreateProcess error=2, Не удается найти указанный файл -> [Help 1]
K>А если установлю себе gpg, то окажется, что сертификата для подписи нет, а потом что я не смогу задеплоить в прописанный репозиторий?
K>Или мне разрешат таки понаписать что попало и задеплоить кривую библиотеку в официальные репозитории?
Ты правда не понимаешь что такое подпись? Что ты тупо не имеешь права подписывать?
Если ты хочешь подеплоить у себя дома для своих друзей, то ты должен использовать свой личный приватный ключ. А если у тебя есть ключ, то тебя должен быть и gpg. Ну или можешь скипнуть шаг подписи "mvn deploy -Dgpg.skip".
K>·>Тут к азуру приколочено.
K>ну, твой pom.xml тоже приколочен же к конкретному репозиторию и умеет только с ним работать
Нет.
K>·>Appveyor какой-то.
K>Это CI, которого я не вижу в pom.xml
Нет.
K>·>Разберись, блин.
K>С чем?
Я тебе ссылку на доку давал. Может ты поанглиццки читать не умеешь?
K>gradlew и gradlew.bat делают одно и то же?
Да. gradlew — это bash для линухов, gradelw.bat — то же для виндов.
K>В gradlew.bat меньше строк?
K>Ну, значит он лучше.
Дядя Петя?
K>·>Потому что это не исходник. Майнтенанс нулевой. И контент идентичный во всём мире. Часть gradle, а не проекта.
K>Он лежит в проекте, значит часть проекта. Завтра в нём обнаружат ошибку/уязвимость и будешь во все свои проекты вносить изменения.
Нет.
K>·>Это привязка к гитхабу. Но проект можно скачать к себе и полноценно использовать у себя без всякого гитхаба.
K>·>Там единственная команда по сути "mvn --batch-mode deploy" — остальное обвязка для паролей-секретов. И собственно всё. В другой инфре это будет другим, ясен пень.
K>т.е. когда в проектах на .NET ровно так же ровно с этой папкой, то это прибито гвоздями, а тут внезапно всё хорошо
Да.
K>·>Как пример что приходится делать.
K>Я ни разу такого не делал почему-то.
Потому что ты не делал переиспользуемые другими компоненты-библиотеки, скорее всего.
K>·>Разберись. Это тест системы тестирования билда.
K>т.е. разработчики идиоты, что делают такие тесты?
А у них есть выбор не делать? Вот ты такой неидиот — закинь им PR, удали им ту папочку и объясни им как это всё сделать кликнув пару тикбоксов в Студии.
K>·>А какой у них был выбор? Какие у них были другие средства и почему они оказались менее удобными?
K>В CI дёргаешь сборку из образа docker, где заведомо есть нужный dotnet и не потребуются скрипты скачивания nuget, msbuild и т.п.
И где это взять готовое и засунуть в мой новый проект? Да ещё и докер локально ставить-настраивать?!
K>В итоге будет небольшой yml, который просто будет dotnet вызывать, как это делают в CI, вызывая mvn deploy
Почему этот небольшой yml ещё никто не написал и не выложил публично?
K>·>Чтобы что?
K>Чтобы в проекте не было лишнего, а деплой был отдельно от сборки.
Чтобы что?
K>А зачем смешивать сборку и деплой в pom.xml, а потом ещё половину деплоя отдельно в CI реализовывать?
Между сборкой и деплоем ты пропустил ещё несколько шагов.
K>Чтобы всё друг к другу гвоздями прибито было?
Не знаю, чтоб всё как ты любишь.