Здравствуйте, karbofos42, Вы писали:
K>·>Не упустил. Суть в том, что pom.xml в 200 строк делает и весь деплой. Иными словами, pom.xml заменяет не только msbuild но и эти портянки скриптов. K>Какой весь? Он скачает и установит maven?
Конечно, не бином ньютона. https://maven.apache.org/wrapper/ но обычно нафиг не надо, и в этом проекте не добавлен.
И для gradle вот тот самый gradew — самоскачивальщик и есть.
K>Установит нужную версию JDK?
maven-compiler-plugin <target>
K>Версию пакета пропишет на основе текущей даты?
Да, но так не надо делать, конечно. Лучше из тега гита выковыривать или из номера билда на соответствующем CI-сервере.
K>Выполнит 8 сборок под разные версии JDK?
Это зачем? Есть такая штука, backward compatibility называется.
K>Данный pom.xml — примерный аналог файлов csproj от Newtonsoft и не более того.
Нет. Ты можешь склонировать проект и запустить полный цикл у себя. Что-нибудь пропатчить, а потом компиляция, тесты, деплоймент, возможно себе локально или внутри своей конторы.
K>·>Именно! И это гно в каждом проекте потребуется. K>Прямо в любом?
Ну да, а ты думал в сказку попал? И каждый выкручивается как может.
K>ReactiveUI
Тут гвоздями к github.com прибито: https://github.com/reactiveui/actions-common/blob/main/.github/workflows/workflow-common-setup-and-build.yml и далее по ссылкам, там такая колбаса...
Скачать исходники к себе и побилдить/подеплоить в свою инфру — надо будет с бубном танцевать.
K>FluentFTP
Вот какая-то фигня https://github.com/robinrodricks/FluentFTP/blob/master/FluentFTP.Dockers/Build.bat
А кроме билда тут вообще ничего нет, ни подписи, ни деплоймента, ни всякого покрытия/анализа когда. Это всё где-то в инфре вендора.
K>fluentmigrator
Тут к азуру приколочено.
K>ClosedXML
Appveyor какой-то.
K>Что-то я не вижу этой кучи скриптов на Powershell.
А они есть.
K>·>Ещё интересно, отлаживались ли эти скрипты под разные версии винды, линуха, мака. K>а должны?
Да.
K>·>Ну во-первых, он собственно необязателен, нужен только для тех кто предпочитает gradle, притом под винду. K>Для справки: под винду gradlew.bat, а gradlew — несколько для других ОС.
Опечатся, имел в виду "и под винду есть". Это Gradle Wrapper. Самозапускальщик. Он везде одинаковый. Создаётся "gradle wrapper" и никогда не меняется, стандартный бинарник по сути: https://docs.gradle.org/current/userguide/gradle_wrapper.html
K>И по твоей логике выходит, что виндовый cmd круче, т.к. равнозначный батник почти в 2 раза меньше, чем файлик для sh.
Разберись, блин.
K>·>Во-вторых, он целиком стандартный автогенерённый файл. Просто коммитят в репу для удобства — после чекаута исходников — сразу запускаешь батник/баш (в зависимости от ОС) и всё работает. K>·>Так что игнорируй этот файл. K>С чего это его игнорировать?
Потому что это не исходник. Майнтенанс нулевой. И контент идентичный во всём мире. Часть gradle, а не проекта.
K>Не видел, чтобы кто-то sln-файлы руками писал, но они почему-то учитывается. csproj тоже обычно IDE сама заполняет и в него особо не заходят.
sln — это solution твоего проекта.
K>А build.gradle тоже не нужно учитывать?
Да, альтернатива maven для любителей.
K>А папку .github/workflows?
Это привязка к гитхабу. Но проект можно скачать к себе и полноценно использовать у себя без всякого гитхаба.
Там единственная команда по сути "mvn --batch-mode deploy" — остальное обвязка для паролей-секретов. И собственно всё. В другой инфре это будет другим, ясен пень.
K>·>Ок. Посмотрел like-for-like. То же самое, от той же конторы: AWS SDK for Java vs c#. Тут в шарпе гна ещё больше — целый многомодульный под-проект для сборки проекта. K>И что? Ну, в AWS так сделали, я тут причём или C# или .NET?
Как пример что приходится делать.
K>·>С тестами даже! Какая прелесть: K>По-моему слова dummy и sample указывают на то, что это какой-то пример, а не реальный тест.
Разберись. Это тест системы тестирования билда.
K>Ну, либо проект делали разработчики с соответствующей квалификацией, что непонятно почему на них ориентироваться нужно.
Я полагаю, что Amazon может себе позволить разработчиков с любой квалификацией.
K>Раз ты считаешь, что они написали смешную чушь, то почему ставишь в пример?
А кого тогда ставить?
K>·>Захотели?! А у них был выбор? Как по-твоему они должны были сделать правильно? K>Если им так удобно, то они всё сделали правильно.
А какой у них был выбор? Какие у них были другие средства и почему они оказались менее удобными?
K>У них нормально разделена сборка и деплой
Чтобы что?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>>·>Кстати я тут поглядел. Взял к примеру json, смотрим на Newtonsoft.Json. Там папочка Build с тысячами строк каких-то зубодробительных скриптов на powershell. sln, .shfbproj, Build.props, NuGet.Config, DotSettings, .csproj, .yml и ещё наверное что-то что упустил. S>>>Странно ветка про XML, а по ссылке таких файлов нет. S>·>Верно. Там такой ужас, что уж лучше бы был XML. S>Мне глубоко наплевать на формат.
Мне тоже. Неясно к чему ты упомянул выше "ветка про XML". Ты уж определись важен тебе XML или не важен.
S> Мне нужна визуальная часть и классы для чтения и записи. Вручную не люблю.
"визуальная часть" vs "Вручную не люблю" — противоречие detected. Визуально это и есть вручную.
S>В той же студии для сборки полно событий до и после сборки.
Э. И?
S>>> Каждый ... так как хочет. S>·>Именно. Стандартный тулчейн просто отсутствует, каждому приходится выкручиваться как "хочет". Добровольно и с песнями (c). S> Стандартный как раз присутствует. Просто они сами заморачиваются. Все есть и можно многое прописывать в настройках.
Да, но это не тул-чейн, а тул-свалка. Собрирать разные тулы в цепочку билда-валидации-анализа-тестирования-деплоя-етс — приходится чем попало.
S>·>Одно время Андроид Студия была свежая и сырая, ей даже десяти лет нет, да и андроиду самому тоже немного. S> Андроиду больше чем .Net Core, однако есть все для отладки на разных платформах итд.
У Андроида тоже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>Мне тоже. Неясно к чему ты упомянул выше "ветка про XML". Ты уж определись важен тебе XML или не важен.
Мне странно, что ветка про XML, а обсуждают json и скрипты S>> Мне нужна визуальная часть и классы для чтения и записи. Вручную не люблю. ·>"визуальная часть" vs "Вручную не люблю" — противоречие detected. Визуально это и есть вручную.
Да ну? Одно дело писать и делать ошибки в файле, другое дело выбирать из предложенного списка или ставить галочки. S>>В той же студии для сборки полно событий до и после сборки. ·>Э. И?
То, что мало кто лезет в сам файл проекта. В большистве случаев это программно в самой студии S>>>> Каждый ... так как хочет. S>>·>Именно. Стандартный тулчейн просто отсутствует, каждому приходится выкручиваться как "хочет". Добровольно и с песнями (c). S>> Стандартный как раз присутствует. Просто они сами заморачиваются. Все есть и можно многое прописывать в настройках. ·>Да, но это не тул-чейн, а тул-свалка. Собрирать разные тулы в цепочку билда-валидации-анализа-тестирования-деплоя-етс — приходится чем попало.
Ну и ... Программно то проще это все сделать. Опят же можно писать в событиях.
S>>·>Одно время Андроид Студия была свежая и сырая, ей даже десяти лет нет, да и андроиду самому тоже немного. S>> Андроиду больше чем .Net Core, однако есть все для отладки на разных платформах итд. ·>У Андроида тоже.
Неее. Я как на Андроид студию перехожу сильно плююсь после VS
В свое время Xamarin явно отставал. Сейчас уже вполне пристойно
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ·, Вы писали:
·>Конечно, не бином ньютона. https://maven.apache.org/wrapper/ но обычно нафиг не надо, и в этом проекте не добавлен. ·>И для gradle вот тот самый gradew — самоскачивальщик и есть.
Так и nuget обычно никому не нужно скачивать и другие разработчики почему-то этим не занимаются, но ты распереживался из-за наличия скрипта для этого в конкретной библиотеке.
·>maven-compiler-plugin <target>
Убрал на компе переменную окружения JAVA_HOME, в pom.xml прописал:
The JAVA_HOME environment variable is not defined correctly,
this environment variable is needed to run this program.
Всё же нужно оказывается окружение для сборки предварительно настраивать.
·>Да, но так не надо делать, конечно. Лучше из тега гита выковыривать или из номера билда на соответствующем CI-сервере.
т.е. нужно гвоздями прибивать к конкретной CI?
·>Это зачем? Есть такая штука, backward compatibility называется.
Затем, что Newtonsoft.Json собирается и под старые рантаймы, где ещё не было асинхронного программирования и т.п.
Другие библиотеки используют для оптимизации, например, Span, которые не так давно появились.
Если ориентироваться под минимальную версию, то не получится задействовать плюшки и оптимизации, доступные в новых версиях.
Если ориентироваться на последние версии, то без библиотеки останутся разработчики под старые фреймворки.
А вот это я так понимаю пример backward compatibility https://github.com/google/gson/issues/2501 ?
·>Нет. Ты можешь склонировать проект и запустить полный цикл у себя. Что-нибудь пропатчить, а потом компиляция, тесты, деплоймент, возможно себе локально или внутри своей конторы.
И откуда возьмётся деплоймент? Может всё же мне придётся брать свою CI, прикручивать к ней вызов какого-нибудь mvn deploy, а в pom.xml переписывать адреса,
а рядом ещё класть какой-нибудь ci_settings.xml для добавления DEPLOY_TOKEN ?
Аналог этой папочки Build в итоге и нужно будет сделать, если захочется такого же деплоймента, который в Newtonsoft.Json сделан
·>Ну да, а ты думал в сказку попал? И каждый выкручивается как может.
Деплоймент всегда делается и должен работать на конкретной инфраструктуре.
Мне вот нужен деплоймент, который сработает изолированно в интранете без всех этих интернетов. И что мне даст gradlew?
K>>ReactiveUI ·>Тут гвоздями к github.com прибито: https://github.com/reactiveui/actions-common/blob/main/.github/workflows/workflow-common-setup-and-build.yml и далее по ссылкам, там такая колбаса... ·>Скачать исходники к себе и побилдить/подеплоить в свою инфру — надо будет с бубном танцевать.
Это для тестов собираются docker-контейнеры для разных FTP-серверов, т.к. протокол сильно произвольный и у каждого сервера своё его видение.
Будешь рассказывать, что это всё не нужно делать и pom.xml в 3 строчки подготовит десяток контейнеров?
·>А кроме билда тут вообще ничего нет, ни подписи, ни деплоймента, ни всякого покрытия/анализа когда. Это всё где-то в инфре вендора.
так и в pom.xml нет деплоймента
Я вот скачал твою библиотеку для json, выполняю mvn deploy и получаю:
[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
run program "gpg.exe": CreateProcess error=2, Не удается найти указанный файл -> [Help 1]
А как так получилось? Всё ведь работает из коробки, нужно просто скачать?
А если установлю себе gpg, то окажется, что сертификата для подписи нет, а потом что я не смогу задеплоить в прописанный репозиторий?
Или мне разрешат таки понаписать что попало и задеплоить кривую библиотеку в официальные репозитории?
·>Тут к азуру приколочено.
ну, твой pom.xml тоже приколочен же к конкретному репозиторию и умеет только с ним работать
·>Appveyor какой-то.
Это CI, которого я не вижу в pom.xml
·>Разберись, блин.
С чем?
gradlew и gradlew.bat делают одно и то же?
В gradlew.bat меньше строк?
Ну, значит он лучше.
·>Потому что это не исходник. Майнтенанс нулевой. И контент идентичный во всём мире. Часть gradle, а не проекта.
Он лежит в проекте, значит часть проекта. Завтра в нём обнаружат ошибку/уязвимость и будешь во все свои проекты вносить изменения.
·>Это привязка к гитхабу. Но проект можно скачать к себе и полноценно использовать у себя без всякого гитхаба. ·>Там единственная команда по сути "mvn --batch-mode deploy" — остальное обвязка для паролей-секретов. И собственно всё. В другой инфре это будет другим, ясен пень.
т.е. когда в проектах на .NET ровно так же ровно с этой папкой, то это прибито гвоздями, а тут внезапно всё хорошо
·>Как пример что приходится делать.
Я ни разу такого не делал почему-то.
·>Разберись. Это тест системы тестирования билда.
т.е. разработчики идиоты, что делают такие тесты?
·>А какой у них был выбор? Какие у них были другие средства и почему они оказались менее удобными?
В CI дёргаешь сборку из образа docker, где заведомо есть нужный dotnet и не потребуются скрипты скачивания nuget, msbuild и т.п.
В итоге будет небольшой yml, который просто будет dotnet вызывать, как это делают в CI, вызывая mvn deploy
·>Чтобы что?
Чтобы в проекте не было лишнего, а деплой был отдельно от сборки.
А зачем смешивать сборку и деплой в pom.xml, а потом ещё половину деплоя отдельно в CI реализовывать?
Чтобы всё друг к другу гвоздями прибито было?
Здравствуйте, 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>[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>А как так получилось? Всё ведь работает из коробки, нужно просто скачать? 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>Чтобы всё друг к другу гвоздями прибито было?
Не знаю, чтоб всё как ты любишь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>·>Мне тоже. Неясно к чему ты упомянул выше "ветка про XML". Ты уж определись важен тебе XML или не важен. S> Мне странно, что ветка про XML, а обсуждают json и скрипты
Ветка про msbuild. Поверх чего — сам заявляешь, что не важно.
S>>> Мне нужна визуальная часть и классы для чтения и записи. Вручную не люблю. S>·>"визуальная часть" vs "Вручную не люблю" — противоречие detected. Визуально это и есть вручную. S> Да ну? Одно дело писать и делать ошибки в файле, другое дело выбирать из предложенного списка или ставить галочки.
автодополнение и подсветку ошибок изобрели ещё в прошлом веке.
S>>>В той же студии для сборки полно событий до и после сборки. S>·>Э. И? S> То, что мало кто лезет в сам файл проекта. В большистве случаев это программно в самой студии
Да потому что ничего интересного-сложного там сделать практически невозможно. В Студии ты будешь, в лучшем случае, батники редактировать.
S>>> Стандартный как раз присутствует. Просто они сами заморачиваются. Все есть и можно многое прописывать в настройках. S>·>Да, но это не тул-чейн, а тул-свалка. Собрирать разные тулы в цепочку билда-валидации-анализа-тестирования-деплоя-етс — приходится чем попало. S> Ну и ... Программно то проще это все сделать. Опят же можно писать в событиях.
А дальше что? Как это будет потом выполняться на CI?
S>·>У Андроида тоже. S> Неее. Я как на Андроид студию перехожу сильно плююсь после VS
Это твои вкусовые пристрастия, спорить об этом не берусь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>>> Мне нужна визуальная часть и классы для чтения и записи. Вручную не люблю. S>·>"визуальная часть" vs "Вручную не люблю" — противоречие detected. Визуально это и есть вручную. S> Да ну? Одно дело писать и делать ошибки в файле, другое дело выбирать из предложенного списка или ставить галочки.
Честно говоря, я не понял какие галочки ты хочешь ставить и зачем. Добавление зависимостей можно и через GUI, я тут уже показывал скриншоты из 2009 года. А большее Студия и не умеет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>>> Мне нужна визуальная часть и классы для чтения и записи. Вручную не люблю. S>>·>"визуальная часть" vs "Вручную не люблю" — противоречие detected. Визуально это и есть вручную. S>> Да ну? Одно дело писать и делать ошибки в файле, другое дело выбирать из предложенного списка или ставить галочки. ·>Честно говоря, я не понял какие галочки ты хочешь ставить и зачем. Добавление зависимостей можно и через GUI, я тут уже показывал скриншоты из 2009 года. А большее Студия и не умеет.
Заходишь в свойства проекта там куча вкладок. На каждой вкладке куча свойств.
Кроме того есть управление нугет пакетами, создавать пакеты, пописывать, порядок сборки. Там хренова туча параметров!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>·>Честно говоря, я не понял какие галочки ты хочешь ставить и зачем. Добавление зависимостей можно и через GUI, я тут уже показывал скриншоты из 2009 года. А большее Студия и не умеет. S>Заходишь в свойства проекта там куча вкладок. На каждой вкладке куча свойств. S>Кроме того есть управление нугет пакетами, создавать пакеты, пописывать, порядок сборки. Там хренова туча параметров!
Каких именно? Поменять Output Directory? И часто ты меняешь?
Как там задаётся запуск тестов, например? Или code coverage проценты? Или генерация документации? Создание docker image?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>·>Честно говоря, я не понял какие галочки ты хочешь ставить и зачем. Добавление зависимостей можно и через GUI, я тут уже показывал скриншоты из 2009 года. А большее Студия и не умеет. S>>Заходишь в свойства проекта там куча вкладок. На каждой вкладке куча свойств. S>>Кроме того есть управление нугет пакетами, создавать пакеты, пописывать, порядок сборки. Там хренова туча параметров! ·>Каких именно? Поменять Output Directory? И часто ты меняешь? ·>Как там задаётся запуск тестов, например? Или code coverage проценты? Или генерация документации? Создание docker image?
Ты когда последний раз студию открывал?
Когда собираешь тесты, они и отрабатывают Краткое руководство. Docker в Visual Studio
Генерации документации какой? Документации по API в XML тоже в студии.
Анализаторы итд. И всегда можно подписаться на событие после сборки и запустить нужные приложения.
Здравствуйте, ·, Вы писали:
·>Ты врёшь. Скрипт не только это делает. Он там много что делает — скачивает не что-то одно, а несколько вещей, потом тулзы в определённом порядке вызывает. ·>Вот тут по-твоему что? https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1#L48-L165 плюс L267-L329 Даже что-то с XML шаманят
Я тебе уже давно перечислил что он делает. То, что ты выделил — очистка рабочей папки.
Эту очистку можно было в 3 строки прописать в csproj, тут захотели отдельным скриптом вручную сделать.
Есть встроенная функция dotnet clean, но там может не всё удаляться. Папки пустые остаются, если сам какие-то ресурсы туда закинул, то останется и т.д.
У меня CI с нуля всегда собирает и очищать ничего не нужно, т.е. это не обязательная вещь.
L267 — версию сборки определяют, это тоже не обязательно делать и в каждом проекте что-то своё могут выдумывать.
Версию можно и через csproj задать, можно и при сборке аргументы прокинуть.
L284 — найдёшь где там вызывается эта функция Edit-XmlNodes ?
L310 — чисто функция чтобы долбить удаление папок из рабочей директории до победного, т.к. какие-то файлы наверно могут быть заняты и сразу не удалится.
·>Анекдот №10056243
А по делу есть что сказать?
·>Не очень понял. А для разработки на дотнете фреймворк не обязателен? ·>В случае mvnw или gradlew нужно только jdk (идёт в поставке с каждой ide для java ну или "apt install" и т.п.). Дальше всё само разворачивается. А у тебя там в скрипте куча чего скачивается и куча шагов выполняется.
Это не у меня в скрипте, а ты взял библиотеку и у меня спрашиваешь почему её разработчики так сделали.
И скрипты эти не для разработки используются, а для деплоя.
На L167 вот ставят .NET SDK
·>Нет, не нужно.
А как без CI и подготовленных скриптов локально потом собирать? Вызывать в командной строке mvn и передавать каждый раз 100500 параметров?
·>Ну там тоже что-то есть для jdk1.6, который был deprecated ещё до выхода Core. Не знаю накой всё ещё держат... наверное удалять просто лень.
В pom.xml же прописано, что собирается под 1.8 где там под 1.6?
Я вот эту фичу даже нагуглить нормально не могу, есть ссылка как это делают в Java?
Нашёл только такое: https://www.baeldung.com/java-multi-release-jar
Выглядит как-то неудобно.
·>Если такое действительно надо, просто добавляют два pom-модуля с разными <target>.
А с кодом что делают? Ну, вот в старой версии не было асинхронной загрузки байт из файла, а в новой появилась.
Мне хочется для старого .NET использовать реализацию с синхронным чтением, а для нового пусть стильное, модное, молодёжное с Async вызывается.
ну, типа как тут: https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/JsonReader.Async.cs
Если собирается без ключа HAVE_ASYNC, то файла в проекте считай нет. Там дальше и отдельные блоки кода включаются/выключаются.
·>Собранная либа на jdk8 будет работать и в jdk21 — это backward compatibility.
Так Newtonsoft собирается и под .NET FW 2.0 и под более современный .NET 6.0.
При этом код для них несколько разный и разный набор методов в сборку попадает, в зависимости от того, что поддерживается в соответствующем рантайме.
·>Из mvn deploy.
Зачем тогда yml для CI github есть, если весь деплой уже в mvn deploy?
·>Можно, но не обязательно. Просто из командной строки "mvn deploy -DaltDeploymentRepository=myCoolRepo..." ну или просто поставить через "mvn install" себе локально, для экспериментов, например.
И это всё каждый раз конечно ручками будет прописываться, а не будут написаны скрипты или не отредактирован уже файл?
·>Поскандалить изволите или так, от чистого сердца? Секреты и пароли, ясен пень надо предъявлять отдельно. На то они и токены-пароли.
Куда отдельно? Какое отдельно? У нас же уже есть деплой и ничего больше не надо.
·>Нет. Как видно по исходникам — не нужно.
т.е. сборка будет выполняться ручками? Каждый раз будут набиваться команды типа mvn clean для очистки рабочей папки, потом вот эти простыни для проброса токенов, репозиториев,...?
·>Молодцы в Майкрософте. Промыть мозги, что б не дай бог, чего б лишнего не захотели. Главное юзеров в узде держать, EEE. Иначе деньги не за что грести будет.
Причём тут Майкрософт? Ты мне тут рассказываешь как в mvn всё хорошо и работает. Только внезапно оказалось, что деплоймент у меня не запускается.
То надо самому для сборки JDK поставить и JAVA_HOME прописать, то ещё чего не так. Где обещанный готовый деплоймент, что ничего не надо у себя разворачивать?
·>Ты должен будешь разместить где-то в этом своём интранете требуемые бинарники. Обычно просто прокси-зеркало делают. Примерно как если ты захочешь в интранете иметь публичные nuget-либы.
И зачем мне этот скрипт с непонятным jar, если я и так сам должен что-то куда-то класть?
Так я лучше соберу docker со всем необходимым и буду его из CI дёргать без всех этих скриптов
·>Какой одной командой запустить весь цикл до деплоя? Компиляция, тесты, сборка, верификация, документация, локальная инсталляция?
Ну, при желании ты в csproj чего угодно можешь прописать. А в реальности оно всё зачем надо?
По рукам бьют, если вызывать больше одной команды?
Или чтобы потом вызывать сборку с ключом maven.test.skip=true ?
А интеграционные и нагрузочные тесты тоже в этой единственной волшебной команде постоянно гоняются?
·>Потому что это описание джобы конкретного CI-сервера.
И откуда-то там 1.6 версия появилась, хотя в pom.xml прописана 1.8.
А как я узнаю из единственной команды, что мои изменения приведут к тому, что под 1.6 больше не собирается?
Ну, вот я у себя при помощи pom.xml делаю локальную сборку, всё собирается, работает, тесты проходят.
А потом джоба для 1.6 точно не упадёт?
·>Из кода там ровно одна строка. На других серверах/локально будешь просто запускать ту же строку передавая информацию о своей конкретной инфраструктуре.
Из кода там 3 файла на пару сотен строк. Под другую инфраструктуру все эти строки нужно будет переписывать или как минимум перепроверять.
Внезапно то же самое, что и в случае с аналогичными файлами библиотек .NET
·>Эээ. Ну да, а что? Ок, не 3 строчки на всё, но по 3 строчки на контейнер — да. integration-test and verify phases.
Охотно верю.
На каждую компиляцию надеюсь будешь все контейнеры у себя поднимать и прогонять тесты?
Ну, и конечно docker локально сам поднимется, ведь там будет специальный плагин для maven?
·>Т.к. в pom.xml нет паролей и приватных ключей, то будем писать километровые батники, чтобы тесты запустить.
·>Ты правда не понимаешь что такое подпись? Что ты тупо не имеешь права подписывать?
Я то понимаю, это ты мне тут рассказываешь что в pom.xml есть всё готовое и работает везде, а вот эти скрипты для .NET пишут от плохой жизни и они не нужны.
·>Если ты хочешь подеплоить у себя дома для своих друзей, то ты должен использовать свой личный приватный ключ. А если у тебя есть ключ, то тебя должен быть и gpg. Ну или можешь скипнуть шаг подписи "mvn deploy -Dgpg.skip".
[ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.3:deploy (injected-nexus-deploy) on project json: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.3:deploy failed: Server credentials with ID "ossrh" not found! -> [Help 1]
Вот так новость
А если ещё раз вызвать, то:
[ERROR] Failed to execute goal org.moditect:moditect-maven-plugin:1.0.0.Final:add-module-info (add-module-infos) on project json: Execution add-module-infos of goal org.moditect:moditect-maven-plugin:1.0.0.Final:add-module-info failed: File F:\User\Downloads\JSON-java-master\target\modules\json-20231013.jar already exists; either set 'overwriteExistingFiles' to true or specify another output directory -> [Help 1]
т.е. оно не умеет очищать само рабочую папку и от этого ломается деплой.
Могли бы хотя бы на powershell скрипт написать, чтобы такого не происходило.
Ты обещал, что в pom.xml есть готовый деплой и всё работает из коробки.
Я попробовал, у меня не работает (я не удивлён, если что).
Где обещанное?
·>Я тебе ссылку на доку давал. Может ты поанглиццки читать не умеешь?
На доку про то почему gradlew.bat короче, чем gradlew? Не помню такого.
·>Дядя Петя?
Так ты тут по строкам кода определяешь крутость.
Почему нельзя аналогичное сравнение тут провести?
·>А у них есть выбор не делать? Вот ты такой неидиот — закинь им PR, удали им ту папочку и объясни им как это всё сделать кликнув пару тикбоксов в Студии.
Мне оно зачем надо? Я этим твоим AWS не пользовался и не собираюсь.
Я понятия не имею зачем они что-то якобы нужное назвали Dummy и Sample и при этом не написали комментариев.
·>И где это взять готовое и засунуть в мой новый проект? Да ещё и докер локально ставить-настраивать?!
Это ты рассказываешь про готовое и что ничего ставить не надо, на деле правда так не работает.
Зависит от проекта и выбранного подхода к деплою.
Зачем локально докер ставить, если за деплой отвечает какая-нибудь CI?
·>Почему этот небольшой yml ещё никто не написал и не выложил публично?
Потому что никому не нужно. Ну, вот gradle сами поставить не в состоянии и таскаете один и тот же скрипт по компам.
Деплой у всех разный и никто не переживает, что целую команду нужно самому написать, а не скопировать.
·>Чтобы что?
Чтобы проект, который разворачивается локально, на тестовом окружении или в продакшене, был один и тот же,
а не вот это, что тут мы для теста перегрузим значение, там репозиторий переназначим, а тут забудем и копипасте и что-то пойдёт не по плану.
·>Между сборкой и деплоем ты пропустил ещё несколько шагов.
Расскажешь почему это разные шаги, а не один шаг и почему вдруг их все нужно выполнять одной командой?
·>Не знаю, чтоб всё как ты любишь.
т.е. всё же в pom.xml всё прибито гвоздями к инфраструктуре?
Здравствуйте, karbofos42, Вы писали:
K>·>Между сборкой и деплоем ты пропустил ещё несколько шагов.
K>Расскажешь почему это разные шаги, а не один шаг и почему вдруг их все нужно выполнять одной командой?
тестирование, например, разной степени автоматизации, включая ручное
Здравствуйте, karbofos42, Вы писали:
K>·>Ты врёшь. Скрипт не только это делает. Он там много что делает — скачивает не что-то одно, а несколько вещей, потом тулзы в определённом порядке вызывает. K>·>Вот тут по-твоему что? https://github.com/JamesNK/Newtonsoft.Json/blob/master/Build/build.ps1#L48-L165 плюс L267-L329 Даже что-то с XML шаманят K>Я тебе уже давно перечислил что он делает. То, что ты выделил — очистка рабочей папки. K>Эту очистку можно было в 3 строки прописать в csproj, тут захотели отдельным скриптом вручную сделать.
Ну забабахай им пулл-реквест.
K>Есть встроенная функция dotnet clean, но там может не всё удаляться. Папки пустые остаются, если сам какие-то ресурсы туда закинул, то останется и т.д.
Гы. Есть, но толком не работает. Ага, полезно. Ещё вопросы накой портянки скриптов писать приходится?
K>У меня CI с нуля всегда собирает и очищать ничего не нужно, т.е. это не обязательная вещь. K>L267 — версию сборки определяют, это тоже не обязательно делать и в каждом проекте что-то своё могут выдумывать.
Именно.
K>Версию можно и через csproj задать, можно и при сборке аргументы прокинуть. K>L284 — найдёшь где там вызывается эта функция Edit-XmlNodes ? K>L310 — чисто функция чтобы долбить удаление папок из рабочей директории до победного, т.к. какие-то файлы наверно могут быть заняты и сразу не удалится.
Мде. У тебя проблемы с чтением. Ты ещё не заметил, что там делается:
Ставится нугет.
Ставится тулза vswhere
Ставится тулза NUnit.ConsoleRunner
Запуск билда
Создаются директории какие-то
Копируются туда-сюда бинарники
Запуск билда документации
Логи билда туда-сюда перемещаются
Создаётся какой-то zip
запуск тестов
ищутся пути к каким-то exe-шкам.
и ещё какие-то хитрвые вспомогательне методы не охота разбираться для чего.
Вот это всё стандартно делается в pom.xml.
K>·>Анекдот №10056243 K>А по делу есть что сказать?
Ну не делай так.
K>·>Не очень понял. А для разработки на дотнете фреймворк не обязателен? K>·>В случае mvnw или gradlew нужно только jdk (идёт в поставке с каждой ide для java ну или "apt install" и т.п.). Дальше всё само разворачивается. А у тебя там в скрипте куча чего скачивается и куча шагов выполняется. K>Это не у меня в скрипте, а ты взял библиотеку и у меня спрашиваешь почему её разработчики так сделали.
Я спрашиваю как же надо было делать-то? И почему им пришлось так делать?
K>И скрипты эти не для разработки используются, а для деплоя.
Это неправда. Запуск тестов и билд документации и т.п. — это не деплой.
K>На L167 вот ставят .NET SDK
Ок. Одна строчка вроде как что-то относительно полезное делает.
K>·>Нет, не нужно. K>А как без CI и подготовленных скриптов локально потом собирать? Вызывать в командной строке mvn и передавать каждый раз 100500 параметров?
Собирать? "mvn package". Ага, вот так просто.
K>·>Ну там тоже что-то есть для jdk1.6, который был deprecated ещё до выхода Core. Не знаю накой всё ещё держат... наверное удалять просто лень. K>В pom.xml же прописано, что собирается под 1.8 где там под 1.6?
Не помню, где-то было, поищи.
K>Я вот эту фичу даже нагуглить нормально не могу, есть ссылка как это делают в Java?
А что там гуглить? Просто в <target> прописываешь нужную версию.
K>Нашёл только такое: https://www.baeldung.com/java-multi-release-jar K>Выглядит как-то неудобно.
Это совсем не то. Это билд одного JAR в котором лежат бинарники из двух разных исходников одного класса. Т.е. можно написать две реализации класса "DateHelper" под разные версии платформы и закатать их в одну банку. И jre будет сама выбирать что использовать в зависимости от версии. Интересно, так .net умеет?
А ты спрашивал как собрать несколько артефактов для разных версий платформы.
K>·>Если такое действительно надо, просто добавляют два pom-модуля с разными <target>. K>А с кодом что делают? Ну, вот в старой версии не было асинхронной загрузки байт из файла, а в новой появилась. K>Мне хочется для старого .NET использовать реализацию с синхронным чтением, а для нового пусть стильное, модное, молодёжное с Async вызывается. K>ну, типа как тут: K>https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/JsonReader.Async.cs K>Если собирается без ключа HAVE_ASYNC, то файла в проекте считай нет. Там дальше и отдельные блоки кода включаются/выключаются.
Ну через compiler-plugin и разруливается — что включать или не включать в список сорс-файлов.
K>·>Собранная либа на jdk8 будет работать и в jdk21 — это backward compatibility. K>Так Newtonsoft собирается и под .NET FW 2.0 и под более современный .NET 6.0. K>При этом код для них несколько разный и разный набор методов в сборку попадает, в зависимости от того, что поддерживается в соответствующем рантайме.
Обычно делают две сборки условно "json-jdk5" "json". Притом "json-jdk5" обычно будет работать и под jdk21. И это в основном актуально для очень разных версий. Т.е. где-то до 6-7 это ещё имеет смысл делать. Начиная с 8 уже вряд ли понадобится. Правда я не знаю кто сейчас вообще jdk7 использует.
K>·>Из mvn deploy. K>Зачем тогда yml для CI github есть, если весь деплой уже в mvn deploy?
Потому что это yml для CI github и ни к mvn ни к java отношения никакого не имеет. Если у тебя будет Jenkins CI, то будет ещё Jenkinsfile. И т.д. Суть в том, что все эти интеграции будут иметь одно единственное "mvn deploy".
K>·>Можно, но не обязательно. Просто из командной строки "mvn deploy -DaltDeploymentRepository=myCoolRepo..." ну или просто поставить через "mvn install" себе локально, для экспериментов, например. K>И это всё каждый раз конечно ручками будет прописываться, а не будут написаны скрипты или не отредактирован уже файл?
Будешь прописывать в своей инфраструктуре или отредактируешь файл.
K>·>Поскандалить изволите или так, от чистого сердца? Секреты и пароли, ясен пень надо предъявлять отдельно. На то они и токены-пароли. K>Куда отдельно? Какое отдельно? У нас же уже есть деплой и ничего больше не надо.
Всё юродствуешь? Ты должен иметь право деплоя, а не только возможность.
K>·>Нет. Как видно по исходникам — не нужно. K>т.е. сборка будет выполняться ручками? Каждый раз будут набиваться команды типа mvn clean для очистки рабочей папки, потом вот эти простыни для проброса токенов, репозиториев,...?
"Простыни" это ты называешь 8 строчек с паролями? Рабочую папку на CI обычно не чистят, т.к. она там всегда свежая. Ну или "git clean", например.
K>·>Молодцы в Майкрософте. Промыть мозги, что б не дай бог, чего б лишнего не захотели. Главное юзеров в узде держать, EEE. Иначе деньги не за что грести будет. K>Причём тут Майкрософт? Ты мне тут рассказываешь как в mvn всё хорошо и работает. Только внезапно оказалось, что деплоймент у меня не запускается.
Ну выпрями себе руки.
K>То надо самому для сборки JDK поставить и JAVA_HOME прописать, то ещё чего не так.
JAVA_HOME прописывает установка JDK. Тебе просто не надо его стирать.
K>Где обещанный готовый деплоймент, что ничего не надо у себя разворачивать?
"Папа, а где море?"
K>·>Ты должен будешь разместить где-то в этом своём интранете требуемые бинарники. Обычно просто прокси-зеркало делают. Примерно как если ты захочешь в интранете иметь публичные nuget-либы. K>И зачем мне этот скрипт с непонятным jar, если я и так сам должен что-то куда-то класть? K>Так я лучше соберу docker со всем необходимым и буду его из CI дёргать без всех этих скриптов Как ты соберёшь докер в своём интранете?
K>·>Какой одной командой запустить весь цикл до деплоя? Компиляция, тесты, сборка, верификация, документация, локальная инсталляция? K>Ну, при желании ты в csproj чего угодно можешь прописать. А в реальности оно всё зачем надо? K>По рукам бьют, если вызывать больше одной команды?
Я просто лениый очень.
K>Или чтобы потом вызывать сборку с ключом maven.test.skip=true ?
Зачем?
K>А интеграционные и нагрузочные тесты тоже в этой единственной волшебной команде постоянно гоняются?
Как скажешь, так и будут гоняться.
K>·>Потому что это описание джобы конкретного CI-сервера. K>И откуда-то там 1.6 версия появилась, хотя в pom.xml прописана 1.8. K>А как я узнаю из единственной команды, что мои изменения приведут к тому, что под 1.6 больше не собирается? K>Ну, вот я у себя при помощи pom.xml делаю локальную сборку, всё собирается, работает, тесты проходят.
В lifecycle можно включить и шаг проверки совместимости с 1.6 если это парит.
K>А потом джоба для 1.6 точно не упадёт?
Пуллреквеста? Да не жалко.
K>·>Из кода там ровно одна строка. На других серверах/локально будешь просто запускать ту же строку передавая информацию о своей конкретной инфраструктуре. K>Из кода там 3 файла на пару сотен строк. Под другую инфраструктуру все эти строки нужно будет переписывать или как минимум перепроверять. K>Внезапно то же самое, что и в случае с аналогичными файлами библиотек .NET
Нет, не то же самое.
K>·>Эээ. Ну да, а что? Ок, не 3 строчки на всё, но по 3 строчки на контейнер — да. integration-test and verify phases. K>Охотно верю. K>На каждую компиляцию надеюсь будешь все контейнеры у себя поднимать и прогонять тесты?
Надейся.
K>Ну, и конечно docker локально сам поднимется, ведь там будет специальный плагин для maven?
Ну можно к удалённому коннектиться.
K>·>Т.к. в pom.xml нет паролей и приватных ключей, то будем писать километровые батники, чтобы тесты запустить. K>·>Ты правда не понимаешь что такое подпись? Что ты тупо не имеешь права подписывать? K>Я то понимаю, это ты мне тут рассказываешь что в pom.xml есть всё готовое и работает везде, а вот эти скрипты для .NET пишут от плохой жизни и они не нужны.
Наконец-то стал что-то понимать.
K>·>Если ты хочешь подеплоить у себя дома для своих друзей, то ты должен использовать свой личный приватный ключ. А если у тебя есть ключ, то тебя должен быть и gpg. Ну или можешь скипнуть шаг подписи "mvn deploy -Dgpg.skip".
K>
K>[ERROR] Failed to execute goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.3:deploy (injected-nexus-deploy) on project json: Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.3:deploy failed: Server credentials with ID "ossrh" not found! -> [Help 1]
K>Вот так новость
Ну так у тебя прав нет на этот сервер. В чём вопрос-то?
K>А если ещё раз вызвать, то: K>
K>[ERROR] Failed to execute goal org.moditect:moditect-maven-plugin:1.0.0.Final:add-module-info (add-module-infos) on project json: Execution add-module-infos of goal org.moditect:moditect-maven-plugin:1.0.0.Final:add-module-info failed: File F:\User\Downloads\JSON-java-master\target\modules\json-20231013.jar already exists; either set 'overwriteExistingFiles' to true or specify another output directory -> [Help 1]
K>т.е. оно не умеет очищать само рабочую папку и от этого ломается деплой.
Ну просто нафиг никому не надо. Но ты можешь прописать, чтобы очищало. Там таже написано как.
K>Могли бы хотя бы на powershell скрипт написать, чтобы такого не происходило.
Могли, но нафиг не надо.
K>Ты обещал, что в pom.xml есть готовый деплой и всё работает из коробки. K>Я попробовал, у меня не работает (я не удивлён, если что).
Ты эту собранную версию уже можешь использовать локально.
K>Где обещанное?
"Папа, где море"
K>·>Я тебе ссылку на доку давал. Может ты поанглиццки читать не умеешь? K>На доку про то почему gradlew.bat короче, чем gradlew? Не помню такого.
Ты дебил или просто троллишь?
K>·>Дядя Петя? K>Так ты тут по строкам кода определяешь крутость.
Это твои фантазии.
K>Почему нельзя аналогичное сравнение тут провести?
Потому что нельзя. Проводи в другом месте.
K>·>А у них есть выбор не делать? Вот ты такой неидиот — закинь им PR, удали им ту папочку и объясни им как это всё сделать кликнув пару тикбоксов в Студии. K>Мне оно зачем надо? Я этим твоим AWS не пользовался и не собираюсь. K>Я понятия не имею зачем они что-то якобы нужное назвали Dummy и Sample и при этом не написали комментариев.
Невежествно — не аргумент.
K>·>И где это взять готовое и засунуть в мой новый проект? Да ещё и докер локально ставить-настраивать?! K>Это ты рассказываешь про готовое и что ничего ставить не надо, на деле правда так не работает.
У тебя руки кривые.
K>Зависит от проекта и выбранного подхода к деплою. K>Зачем локально докер ставить, если за деплой отвечает какая-нибудь CI?
Не знаю, обсуждай свои фантазии с зеркалом. А я разрешаю тебе не ставить.
K>·>Почему этот небольшой yml ещё никто не написал и не выложил публично? K>Потому что никому не нужно. Ну, вот gradle сами поставить не в состоянии и таскаете один и тот же скрипт по компам.
Скрипт нужен чтобы выкачать нужную указанную версию автоматически. А не заставлять каждого дева следить за емейлами что и где и как используется.
K>Деплой у всех разный и никто не переживает, что целую команду нужно самому написать, а не скопировать.
Ну что он разный — это ты сам придумал.
K>·>Чтобы что? K>Чтобы проект, который разворачивается локально, на тестовом окружении или в продакшене, был один и тот же,
Для этого не требуется "разделена сборка и деплой".
K>а не вот это, что тут мы для теста перегрузим значение, там репозиторий переназначим, а тут забудем и копипасте и что-то пойдёт не по плану.
Вот для этого и изобрели pom.xml чтобы все эти детали лежали в проекте в виде кода, а не в твоей любимой "базе знаний".
K>·>Между сборкой и деплоем ты пропустил ещё несколько шагов. K>Расскажешь почему это разные шаги,
Потому что запускаются разные тулзы с разными параметрами.
K>а не один шаг и почему вдруг их все нужно выполнять одной командой?
Чтобы работала машина, а не человек.
K>·>Не знаю, чтоб всё как ты любишь. K>т.е. всё же в pom.xml всё прибито гвоздями к инфраструктуре?
Ты опять врёшь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ну забабахай им пулл-реквест.
Зачем?
·>Гы. Есть, но толком не работает. Ага, полезно. Ещё вопросы накой портянки скриптов писать приходится?
Оно работает так, как заявлено. Я ни разу этого всего не писал, т.к. просто не нужно.
Для локальной сборки я очистку всё равно не делаю и хочется, чтобы быстрее собралось.
Деплой в принципе с нуля всегда делается отдельно и там нечего очищать.
·>Именно.
Что именно? В mvn тоже у каждого свой зоопарк по версиям и кто что только не выдумывает.
Расскажешь как во время исполнения программно версию сборки узнать?
Ну, чтобы в окошко "О программе" вывести, в лог или на страницу info какую, чтобы понятно было какая сборка у пользователя и т.п.
На C# вот я вызываю просто что-то типа:
Assembly.GetExecutingAssembly().GetName().Version
и получаю номер версии, всё работает без внешних зависимостей, которые нужно будет зеркалировать где-то в локальных репозиториях.
Для java после сборки в одну команду вот такие дискуссии: https://stackoverflow.com/questions/3697449/retrieve-version-from-maven-pom-xml-in-code
Выглядит удобно.
·>Мде. У тебя проблемы с чтением. Ты ещё не заметил, что там делается:
Это у тебя по-моему проблемы. Мне в каждом сообщении нужно повторять, что там скачивается nuget и куча остального, чтобы оно запускалось на компе, где ничего не настроено?
Для сборки это всё не нужно. Для деплоя в CI, где настроено окружение это так же не нужно.
Это всё может быть нужно, если кто-то захочет делать деплой со случайного компа.
·>Вот это всё стандартно делается в pom.xml.
Что делается? Я тебе уже привёл пример, что твой pom.xml не работает, если заранее не установить maven и java.
·>Ну не делай так.
Я воспроизвёл ситуацию, когда на компе не настроено окружение, но чуда не произошло.
Скрипты для Newtonsoft в основном своём объёме именно что настраивают окружение.
·>Я спрашиваю как же надо было делать-то? И почему им пришлось так делать?
У них спроси. Выглядит так, что кто-то со времён .NET FW 2.0 как-то привык делать, а сейчас не меняет, т.к. работает и это уже проверено годами.
Собственно там файлы 5 лет назад последний раз правились, ну недавно ещё номер версии поменялся.
·>Это неправда. Запуск тестов и билд документации и т.п. — это не деплой.
Та же Visual Studio прекрасно автоматически прогоняет тесты после каждой компиляции, если это нужно, без всяких скриптов.
Документацию мне зачем каждый раз собирать? Чтобы было время чай попить, пока проект собирается?
·>Собирать? "mvn package". Ага, вот так просто.
И чем это будет отличаться от dotnet build, который отработает без этой папки Build, используя csproj?
K>>Я вот эту фичу даже нагуглить нормально не могу, есть ссылка как это делают в Java?
·>А что там гуглить? Просто в <target> прописываешь нужную версию.
Куда прописывать?
·>Это совсем не то. Это билд одного JAR в котором лежат бинарники из двух разных исходников одного класса. Т.е. можно написать две реализации класса "DateHelper" под разные версии платформы и закатать их в одну банку. И jre будет сама выбирать что использовать в зависимости от версии. Интересно, так .net умеет?
Не уверен, что .net такое умеет, мне собственно и не надо.
Нужна не одна универсальная сборка, а разные.
Чтобы один jar содержал весь код и класс DateHelper для target = 7. Другой jar с тем же самым содержимым, но DateHelper был тот, что соответствует target = 9
·>А ты спрашивал как собрать несколько артефактов для разных версий платформы.
ну, я нашёл только как вызвать сборку с другим target, а как разный код подсунуть для части методов — не понятно.
·>Ну через compiler-plugin и разруливается — что включать или не включать в список сорс-файлов.
Звучит сложно и неудобно.
·>Потому что это yml для CI github и ни к mvn ни к java отношения никакого не имеет. Если у тебя будет Jenkins CI, то будет ещё Jenkinsfile. И т.д. Суть в том, что все эти интеграции будут иметь одно единственное "mvn deploy".
там mvn deploy уже же деплой делает, у него куча плагинов, всё само по репозиториям разлетается и тестируется и дока билдится. Зачем какие-то CI нужны и писать для них скрипты?
·>Всё юродствуешь? Ты должен иметь право деплоя, а не только возможность.
А что мне ещё делать, если я это писал изначально и с этого спор начинался?
·>"Простыни" это ты называешь 8 строчек с паролями? Рабочую папку на CI обычно не чистят, т.к. она там всегда свежая. Ну или "git clean", например.
Ну, вот ты и сам можешь подсказать разработчикам Newtonsoft как нужно рабочую папку очищать без всех этих скриптов на ps.
Правда не знаю даже. "git clean" — это же дополнительная тулза нужна. Не перебор будет по используемым утилитам?
·>Ну выпрями себе руки.
Так ты мне тут уже предлагаешь половину функций деплоймента отключить и в итоге там от него остаётся только компиляция.
·>JAVA_HOME прописывает установка JDK. Тебе просто не надо его стирать.
т.е. надо сначала поставить какую-то JDK, установить maven, а потом уже он со своими волшебными плагинами сможет скачать нужную JDK для сборки и скомпилирует проект?
·> Как ты соберёшь докер в своём интранете?
А как я соберу gradle? Или притащить собранный gradle — это норм, а собранный контейнер — не кошерно?
Для сборки всё равно потребуется куча инструментов. Чем вот это всё по отдельности тащить, добавляя в проекты всякие wrapper'ы,
а потом писать скрипты для CI, с которыми куча своих нюансов в плане отмены, очистки и т.п.
Проще уже эталонный контейнер собрать со всем нужным и из него дёргать.
·>Зачем?
Например, чтобы при компиляции небольшого фикса в GUI для локальной проверки не стартовали тесты, работающие полчаса.
K>>А интеграционные и нагрузочные тесты тоже в этой единственной волшебной команде постоянно гоняются? ·>Как скажешь, так и будут гоняться.
·>В lifecycle можно включить и шаг проверки совместимости с 1.6 если это парит.
Ну, вот в pom.xml этого шага не видно, раз разработчики этой библиотеки его не добавили, значит этим неудобно пользоваться и вообще нет.
·>Ну так у тебя прав нет на этот сервер. В чём вопрос-то?
Я изначально писал, что это не деплой, а бесполезная фигня, которая не будет работать на другой инфраструктуре и толку с неё ноль.
·>Ну просто нафиг никому не надо. Но ты можешь прописать, чтобы очищало. Там таже написано как.
·>Могли, но нафиг не надо.
Забавный ты. Как в .NET что-то сделали — это всё от плохой жизни, как в Java не сделали — нет, а нам и не надо
·>Ты эту собранную версию уже можешь использовать локально.
Я локально собранную версию могу использовать и после mvn package без всего этого деплоя, ровно так же, как Newtonsoft могу собрать через dotnet build без использования папки Build.
·>Ты дебил или просто троллишь?
Ну, ты говоришь, что csproj плохой, т.к. много всего понаписано и до кучи нужно много скриптов писать, а в pom.xml якобы то же самое сделано короче и потому он лучше.
Даже привёл какие-то проекты от AWS.
Ну, вот есть gradlew.bat и gradlew, которые делают одно и то же, но батник почти в 2 раза меньше.
Согласен, что виндовые команды круче линуксовых, ведь на них писанины сильно меньше понадобилось?
·>Потому что нельзя. Проводи в другом месте.
Я тут хочу.
·>Невежествно — не аргумент.
Ну, ты вот не знаешь, что внутрь csproj можно засунуть и подписание и публикацию и много всего интересного и как-то живёшь с этим
·>У тебя руки кривые.
Или инструменты плохие.
·>Скрипт нужен чтобы выкачать нужную указанную версию автоматически. А не заставлять каждого дева следить за емейлами что и где и как используется.
Можно админов научить ПО в AD накатывать, а то так и git забудут обновить или LFS не поставят и работать не будет.
·>Ну что он разный — это ты сам придумал.
А чего тогда у всех твоих примеров на Java разный деплой?
·>Для этого не требуется "разделена сборка и деплой".
Так же как можно и все проекты в один репозиторий класть, очень удобно.
·>Вот для этого и изобрели pom.xml чтобы все эти детали лежали в проекте в виде кода, а не в твоей любимой "базе знаний".
Ну, когда все репозитории прописаны в одном файле, то по-любому не ошибёшься и не то не туда не положишь.
А если раскидать по разным скриптам и конфигам — наверняка опростоволосишься.
·>Потому что запускаются разные тулзы с разными параметрами.
Какие разные? У нас же maven всё делает в одну команду при помощи единственного pom.xml, а другие тулзы лень использовать.
K>>а не один шаг и почему вдруг их все нужно выполнять одной командой? ·>Чтобы работала машина, а не человек.
·>Ты опять врёшь.
Где я вру? Ну, ты вот в качестве примера дал pom.xml, написал что там готовый деплой.
По факту в нём прописан какой-то репозиторий, там какая-то цифровая подпись нужна.
В итоге мне нужно там будет переделывать на свою цифровую подпись или это убирать, нужно менять репозиторий для публикации, как-то где-то прописывать токен или логин+пароль для заливки в этот репозиторий.
Ну, и в итоге половину этого pom.xml придётся изменить. А если я захочу форк сделать и поддерживать эту библиотеку,
подтягивая изменения из оригинального репозитория, то у меня в этом файле полезут конфликты, которые каждый раз нужно будет разруливать.
Всё это ради чего? Чтобы конфиг публикации в отдельный файл не выносить, т.к. слишком много файлов на диске будет лежать?
Или чтобы всё подряд строго одной командой делать, т.к. от двух строк уже кто-то умрёт?
Здравствуйте, karbofos42, Вы писали:
K>·>Ну забабахай им пулл-реквест. K>Зачем?
Чтобы код был проще. Сделаешь людям добро.
K>·>Гы. Есть, но толком не работает. Ага, полезно. Ещё вопросы накой портянки скриптов писать приходится? K>Оно работает так, как заявлено.
Но не как надо, поэтому им пришлось писать скрипты.
K>Я ни разу этого всего не писал, т.к. просто не нужно. K>Для локальной сборки я очистку всё равно не делаю и хочется, чтобы быстрее собралось. K>Деплой в принципе с нуля всегда делается отдельно и там нечего очищать.
Но почему-то к тому мавену прикопался, что он якобы не делает ненужную очистку. Если тебе так хочется с очисткой, то "mvn clean deploy".
K>·>Именно. K>Что именно? В mvn тоже у каждого свой зоопарк по версиям и кто что только не выдумывает.
Зоопарк в том как номера версий генерить — т.к. дело вкуса по сути.
Ну и ещё сложности возникают в том, что иногда бывает сложно решить, что же собственно считать версией системы — она может состоять из многих компонент, в том числе динамически подгружаемых.
K>Расскажешь как во время исполнения программно версию сборки узнать? K>Ну, чтобы в окошко "О программе" вывести, в лог или на страницу info какую, чтобы понятно было какая сборка у пользователя и т.п. K>На C# вот я вызываю просто что-то типа: K>
Что тебя опять не устраивает?
K>·>Мде. У тебя проблемы с чтением. Ты ещё не заметил, что там делается: K>Это у тебя по-моему проблемы. Мне в каждом сообщении нужно повторять, что там скачивается nuget и куча остального, чтобы оно запускалось на компе, где ничего не настроено?
Там не только скачивание. Ты опять половину проигнорировал.
K>Для сборки это всё не нужно. Для деплоя в CI, где настроено окружение это так же не нужно.
Нужно. Если ты не обратил внимание, там ещё есть .appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy".
K>Это всё может быть нужно, если кто-то захочет делать деплой со случайного компа.
Кто в принципе захочет делать деплой.
K>·>Вот это всё стандартно делается в pom.xml. K>Что делается? Я тебе уже привёл пример, что твой pom.xml не работает, если заранее не установить maven и java.
Ну и "runbuild.ps1" не работает без "image: Visual Studio 2017". Чё сказать-то хотел?
K>·>Ну не делай так. K>Я воспроизвёл ситуацию, когда на компе не настроено окружение, но чуда не произошло. K>Скрипты для Newtonsoft в основном своём объёме именно что настраивают окружение.
Угу. Верно, эти скрипты делают ровно то же, что и pom.xml. И тоже не работают без окружения в виде "environment: VisualStudioVersion: 15.0". Чё сказать-то хотел?
K>·>Я спрашиваю как же надо было делать-то? И почему им пришлось так делать? K>У них спроси. Выглядит так, что кто-то со времён .NET FW 2.0 как-то привык делать, а сейчас не меняет, т.к. работает и это уже проверено годами. K>Собственно там файлы 5 лет назад последний раз правились, ну недавно ещё номер версии поменялся.
Как же надо делать-то сейчас?
K>·>Это неправда. Запуск тестов и билд документации и т.п. — это не деплой. K>Та же Visual Studio прекрасно автоматически прогоняет тесты после каждой компиляции, если это нужно, без всяких скриптов.
И IDEA тоже.
K>Документацию мне зачем каждый раз собирать? Чтобы было время чай попить, пока проект собирается?
Чтобы посмотреть как она выглядит. Или читать из соседнего проекта. Да тупо банально проверить что она таки собирается перед коммитом.
K>·>Собирать? "mvn package". Ага, вот так просто. K>И чем это будет отличаться от dotnet build, который отработает без этой папки Build, используя csproj?
В том, что реальный билд делается вот такой командой:
Чем она отличается от "dotnet build" и чем в принципе может отличаться я разбираться не хочу, совершенно. Факт, в том, что она уже отличается и это потенциальный источник ошибок.
А вот "mvn package" делает ровно то же, что и "mvn deploy" до той же фазы.
K>>>Я вот эту фичу даже нагуглить нормально не могу, есть ссылка как это делают в Java? K>·>А что там гуглить? Просто в <target> прописываешь нужную версию. K>Куда прописывать?
В pom.xml
K>·>Это совсем не то. Это билд одного JAR в котором лежат бинарники из двух разных исходников одного класса. Т.е. можно написать две реализации класса "DateHelper" под разные версии платформы и закатать их в одну банку. И jre будет сама выбирать что использовать в зависимости от версии. Интересно, так .net умеет? K>Не уверен, что .net такое умеет, мне собственно и не надо.
Именно это тебе скорее всего может понадобиться. Но дотнет не умеет, вот и приходится извращаться.
K>Нужна не одна универсальная сборка, а разные.
Я так и не понял зачем.
K>Чтобы один jar содержал весь код и класс DateHelper для target = 7. Другой jar с тем же самым содержимым, но DateHelper был тот, что соответствует target = 9
У него, наверняка, будет идентичный байткод. Только сигнатура версии будет другая. Я что-то не могу с ходу придумать что в принципе может отличаться...
Но это лирика. Если тебе действительно захочется так сделать из любви к искусству, то просто пишешь либо два модуля с одним и тем же src но разным конфигом maven-compiler-plugin, либо можно сделать исполнение плагина дважды в одном модуле с разным out-dir. Потом собрать две jar-ки из этого.
K>·>А ты спрашивал как собрать несколько артефактов для разных версий платформы. K>ну, я нашёл только как вызвать сборку с другим target, а как разный код подсунуть для части методов — не понятно.
В смысле что-то типа условной компиляции как в C? #ifdef? Такого нет, и уверен, что не будет, слишком бессмысленное и беспощадное решение. Multiplatform как у тебя выше по ссылке — имеет смысл. Минимальная единица компиляции — класс. Те части методов, которые отличаются выносятся в отдельный класс.
K>·>Ну через compiler-plugin и разруливается — что включать или не включать в список сорс-файлов. K>Звучит сложно и неудобно.
Для твоего случая с Async это и не нужно. Проще класс добавить в ту же сборку. Клиенты со старой версией не смогут его всё равно использовать. Зато просто проапгрейдя версию платформы, сразу будут иметь и этот класс.
K>·>Потому что это yml для CI github и ни к mvn ни к java отношения никакого не имеет. Если у тебя будет Jenkins CI, то будет ещё Jenkinsfile. И т.д. Суть в том, что все эти интеграции будут иметь одно единственное "mvn deploy". K>там mvn deploy уже же деплой делает, у него куча плагинов, всё само по репозиториям разлетается и тестируется и дока билдится. Зачем какие-то CI нужны и писать для них скрипты?
CI нужны для автоматической сборки: триггер на изменение в гите, запуск билда, уведомления по емейлу, проверка пулл-реквестов, рисование отчётов и т.п.
K>·>Всё юродствуешь? Ты должен иметь право деплоя, а не только возможность. K>А что мне ещё делать, если я это писал изначально и с этого спор начинался?
А ты почитай с чего спор начинался.
K>·>"Простыни" это ты называешь 8 строчек с паролями? Рабочую папку на CI обычно не чистят, т.к. она там всегда свежая. Ну или "git clean", например. K>Ну, вот ты и сам можешь подсказать разработчикам Newtonsoft как нужно рабочую папку очищать без всех этих скриптов на ps. K>Правда не знаю даже. "git clean" — это же дополнительная тулза нужна. Не перебор будет по используемым утилитам?
Не понял. А как ещё по-твоему на компе код проекта появиться может?
K>·>Ну выпрями себе руки. K>Так ты мне тут уже предлагаешь половину функций деплоймента отключить и в итоге там от него остаётся только компиляция.
Нет. Я предлагаю мозги включить. Я заявлял, что pom.xml заменяет все .csproj, .sln, psake, Build/ и прочее гно. Ты мне начал бред про отсутствие паролей и секретов нести. Попробуй сделай ровно то же с Newtonsoft.Json — выкачай их репу и задеплой на официальный сервер сборку, подписанную. Удачи.
Но если у тебя это не выйдет, попробуй хотя бы неподписаннную сборку задеплоить на какой-нибудь свой сервер или локально, аналог "mvn deploy -Dgpg.skip -DaltDeploymentRepository=local::default::file:/tmp/repo". Уверен, что ты и это не сможешь. Как минимум придётся модифицировать скрипты.
K>·>JAVA_HOME прописывает установка JDK. Тебе просто не надо его стирать. K>т.е. надо сначала поставить какую-то JDK, установить maven, а потом уже он со своими волшебными плагинами сможет скачать нужную JDK для сборки и скомпилирует проект?
Да, примерно. И мавен ставить тоже необязательно. Если установка мавена тебя парит — используй mvnw.
K>·> Как ты соберёшь докер в своём интранете? K>А как я соберу gradle? Или притащить собранный gradle — это норм, а собранный контейнер — не кошерно?
Твоё утверждение было, что это лучше. Чем — ты секрет не раскрыл.
Не лучше, хотя бы в том, что бинарик gradle весит несколько мегабайт. docker image и вся инфра для него — гигабайты.
K>Для сборки всё равно потребуется куча инструментов. Чем вот это всё по отдельности тащить, добавляя в проекты всякие wrapper'ы,
Каких? Ещё раз — jdk — единственный необходимый инструмент.
K>а потом писать скрипты для CI, с которыми куча своих нюансов в плане отмены, очистки и т.п.
Пишется не скрипт для CI, а описание джобы в CI. Команда там одна "mvn deploy".
Кстати, например, тот же Jenkins умеет более плотно интегрироваться с maven и он оттуда автоматически подхватит артефакты, всякие отчёты о результатах тестов, покрытия кода, findbugs, проверок стиля и т.п. Будет вести статистику между билдами и т.д.
K>Проще уже эталонный контейнер собрать со всем нужным и из него дёргать.
Для msbuild — проще, верю. Для mvn — это тоже можно сделать, но это не проще.
K>·>Зачем? K>Например, чтобы при компиляции небольшого фикса в GUI для локальной проверки не стартовали тесты, работающие полчаса.
"mvn compile", если ты вдруг почему-то IDE не хочешь использовать.
K>Ну, вот в pom.xml этого шага не видно, раз разработчики этой библиотеки его не добавили, значит этим неудобно пользоваться и вообще нет.
Да пофиг на 1.6.
K>·>Ну так у тебя прав нет на этот сервер. В чём вопрос-то? K>Я изначально писал, что это не деплой, а бесполезная фигня, которая не будет работать на другой инфраструктуре и толку с неё ноль.
Будет работать и на другой инфре, если у тебя есть права. В отличие от Build/, на который у тебя, внезапно, тоже прав нет.
K>·>Ну просто нафиг никому не надо. Но ты можешь прописать, чтобы очищало. Там таже написано как. K>·>Могли, но нафиг не надо. K>Забавный ты. Как в .NET что-то сделали — это всё от плохой жизни, как в Java не сделали — нет, а нам и не надо
Тут не в Java не сделали, а разработчик не сделал в этом конкретном проекте — ибо это вообще никому не нужно.
K>·>Ты эту собранную версию уже можешь использовать локально. K>Я локально собранную версию могу использовать и после mvn package без всего этого деплоя, ровно так же, как Newtonsoft могу собрать через dotnet build без использования папки Build.
И задеплоить на свой внутренний сервер nuget например для коллег?
K>·>Ты дебил или просто троллишь? K>Ну, ты говоришь, что csproj плохой, т.к. много всего понаписано и до кучи нужно много скриптов писать, а в pom.xml якобы то же самое сделано короче и потому он лучше.
Похоже таки первое. Ок. Разжую.
Этот файлик "gradlew" пишется одной строчкой "gradle wrapper". ОДНА СТРОЧКА КОДА требуется от девелопера. Что эта строчка кода создаёт некий файлик определённого размера — интересует только тебя.
Я тебе страшную вещь ещё скажу. Эта же строчка генерит и "gradle/wrapper/gradle-wrapper.jar" — загляни туда и представь как бедные java-девелоперы всю ночь это набивают в hex-редакторе по бумажке.
K>Даже привёл какие-то проекты от AWS. K>Ну, вот есть gradlew.bat и gradlew, которые делают одно и то же, но батник почти в 2 раза меньше. K>Согласен, что виндовые команды круче линуксовых, ведь на них писанины сильно меньше понадобилось?
Мде. Ок. Попробую с другой стороны. Эти файлы ты можешь смело удалить из проекта: "rm -r *gradle*". Ничего не изменится. Вообще.
K>Я тут хочу.
Хоти.
K>·>Невежествно — не аргумент. K>Ну, ты вот не знаешь, что внутрь csproj можно засунуть и подписание и публикацию и много всего интересного и как-то живёшь с этим
Я знаю, что можно. Но я ещё знаю, что лучше не нужно.
K>·>У тебя руки кривые. K>Или инструменты плохие.
Нет. Просто руки кривые.
K>·>Скрипт нужен чтобы выкачать нужную указанную версию автоматически. А не заставлять каждого дева следить за емейлами что и где и как используется. K>Можно админов научить ПО в AD накатывать, а то так и git забудут обновить или LFS не поставят и работать не будет.
Ага-ага. Потом ты админам расскажи, что разные проекты и даже разные ветки того же проекта оказывается могут использовать разные версии gradle. И при выходе новой версии — каждый раз пропинывать админов, чтоб занять их чем-нибудь.
K>·>Ну что он разный — это ты сам придумал. K>А чего тогда у всех твоих примеров на Java разный деплой?
Чё?
K>·>Для этого не требуется "разделена сборка и деплой". K>Так же как можно и все проекты в один репозиторий класть, очень удобно.
ms/facebook/google так и делают афаир.
K>·>Вот для этого и изобрели pom.xml чтобы все эти детали лежали в проекте в виде кода, а не в твоей любимой "базе знаний". K>Ну, когда все репозитории прописаны в одном файле, то по-любому не ошибёшься и не то не туда не положишь. K>А если раскидать по разным скриптам и конфигам — наверняка опростоволосишься.
Ты не понял. Этот файл один на весь мир. Например, "skip gpg maven plugin" — будет первый резульат в гугле, ответ найдёшь за 5 секунд. А как отключить подписывание в Newtonsoft.Json? А в каждой из перечисленных тобой выше по топику либ?
K>·>Потому что запускаются разные тулзы с разными параметрами. K>Какие разные? У нас же maven всё делает в одну команду при помощи единственного pom.xml, а другие тулзы лень использовать.
Одна команда maven запускает разные тулзы с разными параметрами.
K>Где я вру? Ну, ты вот в качестве примера дал pom.xml, написал что там готовый деплой.
Я написал, что он функционально соответствует Build/ и т.д.
K>По факту в нём прописан какой-то репозиторий, там какая-то цифровая подпись нужна.
В Build/ тоже всякая хрень прописана. В том числе и абсолютный путь C:\ до файла с подписью. Которой, внезапно у тебя тоже нет. И быть не может.
K>В итоге мне нужно там будет переделывать на свою цифровую подпись или это убирать, нужно менять репозиторий для публикации, как-то где-то прописывать токен или логин+пароль для заливки в этот репозиторий.
Не нужно, а можно. С Build/ — кстати, нельзя. Там, кстати, даже собсвенно делпоя я что-то не вижу. Там просто собирается zip, а где код заливки на сервер?
K>Ну, и в итоге половину этого pom.xml придётся изменить.
Нет, не придётся.
K>А если я захочу форк сделать и поддерживать эту библиотеку,
В смысле внутри своей организации? Создашь job в своём CI и там передашь данные своей инфры через парамы/переменные окружения.
K>подтягивая изменения из оригинального репозитория, то у меня в этом файле полезут конфликты, которые каждый раз нужно будет разруливать.
Они могут полезть. И не только в этом файле, но и в любой части исходников. И не потому что у тебя другая инфра, а потому что форк.
K>Всё это ради чего? Чтобы конфиг публикации в отдельный файл не выносить, т.к. слишком много файлов на диске будет лежать?
Всё ради того, чтобы не требовалось строчить строчки ad-hoc скриптов.
K>Или чтобы всё подряд строго одной командой делать, т.к. от двух строк уже кто-то умрёт?
В Build/ не две строки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Чтобы код был проще. Сделаешь людям добро.
Так ты за них переживаешь, вот научи как делать правильно и без скриптов или напиши универсальные скрипты, которые всем помогут
·>Но не как надо, поэтому им пришлось писать скрипты.
Так у них там workingDir — это вообще не та папка, куда MSBuild собирает.
Не нравится им из bin/Release файлы собирать, вот таскают туда, потом вручную очищают.
Могли просто OutputPath переназначить при вызове dotnet build
·>Но почему-то к тому мавену прикопался, что он якобы не делает ненужную очистку. Если тебе так хочется с очисткой, то "mvn clean deploy".
Где я прикопался? Ты тут строки сравниваешь, вот тогда сравнивай весь функционал.
И в какую папку он всё соберёт, этот твой mvn? В target? Где кроме jar будет ещё куча папок?
А где перенос в нужную workingDir только нужного?
·>Зоопарк в том как номера версий генерить — т.к. дело вкуса по сути. ·>Ну и ещё сложности возникают в том, что иногда бывает сложно решить, что же собственно считать версией системы — она может состоять из многих компонент, в том числе динамически подгружаемых.
У меня так null получается, хотя в META-INF/MANIFEST.MF версия прописана.
И не только у меня руки кривые, там в комментариях у народа так же null.
В итоге надо в application.yml добавить какой-нибудь конфиг, в него записать @project.version@, а потом его уже читать.
Очень удобно, в одну строку и никаких потенциальных ошибок.
·>Там не только скачивание. Ты опять половину проигнорировал.
Если убрать скрипты, которые делают то, что не делает maven, то там останется не так уж много, чтобы из-за этого переживать.
·>Нужно. Если ты не обратил внимание, там ещё есть .appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy".
Чем соответствует? mvn deploy автоматически вызывается на билд-сервере для указанных там веток?
·>Кто в принципе захочет делать деплой.
Ну, у меня на компе нужные инструменты есть, мне большинство этих скриптов не нужно
·>Ну и "runbuild.ps1" не работает без "image: Visual Studio 2017". Чё сказать-то хотел?
Врёшь же. У меня нет Visual Studio 2017 и скрипт почему-то запустился и отработал.
Вот даже SDK нужный скачал
·>Угу. Верно, эти скрипты делают ровно то же, что и pom.xml. И тоже не работают без окружения в виде "environment: VisualStudioVersion: 15.0". Чё сказать-то хотел?
Покажешь где требование к такому окружению есть?
·>Как же надо делать-то сейчас?
Кому как нравится. Я тебе привёл пример библиотек без кучи скриптов, но тебе не понравилось.
Кто хочет — может всё в csproj засунуть и будет то же самое, что с pom.xml, даже функциональнее.
·>Чтобы посмотреть как она выглядит. Или читать из соседнего проекта. Да тупо банально проверить что она таки собирается перед коммитом.
т.е. когда в десктопном приложении ты изменишь надпись на кнопке или поменяешь разметку страницы, возвращаемой сервером, то билдишь документацию и перепроверяешь не поломалась ли она?
K>>·>Собирать? "mvn package". Ага, вот так просто. K>>И чем это будет отличаться от dotnet build, который отработает без этой папки Build, используя csproj? ·>В том, что реальный билд делается вот такой командой: ·>
·>Чем она отличается от "dotnet build" и чем в принципе может отличаться я разбираться не хочу, совершенно. Факт, в том, что она уже отличается и это потенциальный источник ошибок. ·>А вот "mvn package" делает ровно то же, что и "mvn deploy" до той же фазы.
Реальный билд делается сильно короче, а тут прописывается версия, ИД пакета, подпись.
mvn package твой так же потребует всё это передавать, если будет нужно версию снаружи получать, профиль сборки и т.д.
В прошлом сообщении ты оправдывал наличие CI тем, что там только параметры для сборки передаются, теперь рассказываешь, что их якобы не надо передавать.
Чтобы mavn package не отличался от mvn deploy, им нужно одинаковые параметры на вход передавать и примерно такая же команда будет.
·>Именно это тебе скорее всего может понадобиться. Но дотнет не умеет, вот и приходится извращаться.
Зачем оно мне надо? Если у меня приложение под .NET FW 2.0, то мне NuGet пришлёт нужную сборку. Зачем мне тащить к себе огромную библиотеку, которая будет содержать код для нескольких версий рантайма?
Чтобы моё приложение солиднее выглядело из-за объёма?
·>Я так и не понял зачем.
А ты себе скачиваешь приложения для всего подряд? Ну, чтобы и на x86, x64 и arm работало? А то вдруг железо поменяешь, надо, чтобы на любом запускалось?
·>У него, наверняка, будет идентичный байткод. Только сигнатура версии будет другая. Я что-то не могу с ходу придумать что в принципе может отличаться...
Ну, если написать код с использованием Virtual Threads, то он будет работать на 1.8 ?
·>Но это лирика. Если тебе действительно захочется так сделать из любви к искусству, то просто пишешь либо два модуля с одним и тем же src но разным конфигом maven-compiler-plugin, либо можно сделать исполнение плагина дважды в одном модуле с разным out-dir. Потом собрать две jar-ки из этого.
в общем, сложно и неудобно.
·>В смысле что-то типа условной компиляции как в C? #ifdef? Такого нет, и уверен, что не будет, слишком бессмысленное и беспощадное решение. Multiplatform как у тебя выше по ссылке — имеет смысл. Минимальная единица компиляции — класс. Те части методов, которые отличаются выносятся в отдельный класс.
А по-моему удобная вещь, когда нужно поддерживать разные варианты сборки.
·>Для твоего случая с Async это и не нужно. Проще класс добавить в ту же сборку. Клиенты со старой версией не смогут его всё равно использовать. Зато просто проапгрейдя версию платформы, сразу будут иметь и этот класс.
Зачем мне с собой таскать код, который не могу вызывать?
·>CI нужны для автоматической сборки: триггер на изменение в гите, запуск билда, уведомления по емейлу, проверка пулл-реквестов, рисование отчётов и т.п.
Ты в этом же сообщении чуть выше утверждал, что ".appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy""
·>А ты почитай с чего спор начинался.
·>Не понял. А как ещё по-твоему на компе код проекта появиться может?
Ну, я вот с github скачал zip-архив и распаковал.
·>Нет. Я предлагаю мозги включить. Я заявлял, что pom.xml заменяет все .csproj, .sln, psake, Build/ и прочее гно. Ты мне начал бред про отсутствие паролей и секретов нести. Попробуй сделай ровно то же с Newtonsoft.Json — выкачай их репу и задеплой на официальный сервер сборку, подписанную. Удачи. ·>Но если у тебя это не выйдет, попробуй хотя бы неподписаннную сборку задеплоить на какой-нибудь свой сервер или локально, аналог "mvn deploy -Dgpg.skip -DaltDeploymentRepository=local::default::file:/tmp/repo". Уверен, что ты и это не сможешь. Как минимум придётся модифицировать скрипты.
Я тебе сразу говорил, что pom.xml в таком виде говно, т.к. придётся переписывать в нём репозитории и править под свою инфраструктуру. Если мне не нужна подпись, то я уберу просто этот блок из pom.xml, а не буду кучу параметров прокидывать. В итоге из рабочего остаётся только билд, а деплой нужно весь переделывать под то, что мне будет нужно.
·>Да, примерно. И мавен ставить тоже необязательно. Если установка мавена тебя парит — используй mvnw.
Ну, а скрипт на powershell скачиваешь .NET SDK и ему мавен никакой не нужен.
·>Твоё утверждение было, что это лучше. Чем — ты секрет не раскрыл. ·>Не лучше, хотя бы в том, что бинарик gradle весит несколько мегабайт. docker image и вся инфра для него — гигабайты.
docker image один и в нём всё нужное будет. gradle — один из инструментов, который нужно будет ещё настраивать (прописывать в проекте для gradlew где искать этот самый gradle и загружать к себе)
·>Каких? Ещё раз — jdk — единственный необходимый инструмент.
А git ты откуда брать будешь, чтобы код репозитория подтянулся?
·>Пишется не скрипт для CI, а описание джобы в CI. Команда там одна "mvn deploy".
Прямо такая "mvn deploy"? Или там для dev-сборки одна команда, для релиза — другая и в каждую куча параметров передаётся?
·>Кстати, например, тот же Jenkins умеет более плотно интегрироваться с maven и он оттуда автоматически подхватит артефакты, всякие отчёты о результатах тестов, покрытия кода, findbugs, проверок стиля и т.п. Будет вести статистику между билдами и т.д.
Ну, нигде больше такого нет
·>Для msbuild — проще, верю. Для mvn — это тоже можно сделать, но это не проще.
Ну, да. Проще каждую сборку окружение настраивать, чем один раз образ подготовить.
·>"mvn compile", если ты вдруг почему-то IDE не хочешь использовать.
Выполнил, не могу найти jar-файл.
·>Да пофиг на 1.6.
Ну, мне и на .NET FW 2.0 пофиг, а разработчики Newtonsoft.Json поддерживают его.
·>Будет работать и на другой инфре, если у тебя есть права. В отличие от Build/, на который у тебя, внезапно, тоже прав нет.
Как он будет работать, если у меня другие адреса и способ подписания будут?
Сам проанализирует инфраструктуру и подстроится или мне нужно будет переписывать pom.xml под свои нужды?
·>Тут не в Java не сделали, а разработчик не сделал в этом конкретном проекте — ибо это вообще никому не нужно.
А почему когда что-то только в Newtonsoft.Json сделано, ты выдаёшь за аргумент, что значит в .NET так все вынуждены делать?
·>И задеплоить на свой внутренний сервер nuget например для коллег?
Да. Придётся правда пересилить себя и написать целую одну команду: nuget push
·>Похоже таки первое. Ок. Разжую. ·>Этот файлик "gradlew" пишется одной строчкой "gradle wrapper". ОДНА СТРОЧКА КОДА требуется от девелопера. Что эта строчка кода создаёт некий файлик определённого размера — интересует только тебя. ·>Я тебе страшную вещь ещё скажу. Эта же строчка генерит и "gradle/wrapper/gradle-wrapper.jar" — загляни туда и представь как бедные java-девелоперы всю ночь это набивают в hex-редакторе по бумажке.
Причём тут gradle и что он делает?
Файл gradlew.bat меньше, чем файл gradlew, значит команды батника мощнее и круче, т.к. позволяют то же самое делать меньшим числом строк.
·>Мде. Ок. Попробую с другой стороны. Эти файлы ты можешь смело удалить из проекта: "rm -r *gradle*". Ничего не изменится. Вообще.
Так командная строка винды круче линуксовой, т.к. меньше строк кода удалить нужно, чтобы они продолжали быть бесполезными?
Кстати, расскажи разработчикам этого скрипта и jar, что они сделали никому ненужную фигню.
·>Чё?
Ну, тут несколько примеров на Java было и у всех разный деплой, а ты говоришь, что "Ну что он разный — это ты сам придумал"
K>>·>Для этого не требуется "разделена сборка и деплой". K>>Так же как можно и все проекты в один репозиторий класть, очень удобно. ·>ms/facebook/google так и делают афаир.
·>Ты не понял. Этот файл один на весь мир. Например, "skip gpg maven plugin" — будет первый резульат в гугле, ответ найдёшь за 5 секунд.
Какой файл один на весь мир? pom.xml с кучей репозиториев на все случи жизни?
.>А как отключить подписывание в Newtonsoft.Json? А в каждой из перечисленных тобой выше по топику либ?
Не вызывать скрипт подписания. В других либах по-моему не во всех вообще подпись была, я не смотрел.
·>Я написал, что он функционально соответствует Build/ и т.д.
А я тебе написал, что не соответствует и указал чем.
·>В Build/ тоже всякая хрень прописана. В том числе и абсолютный путь C:\ до файла с подписью. Которой, внезапно у тебя тоже нет. И быть не может.
Так мне эта папка и не нужна. Я её выкину и сделаю свой деплой.
С pom.xml тоже нужно будет всё под себя делать, но не получится выкинуть что-то отдельное, а придётся ковырять куски проекта.
Потом когда через год я захочу влить к себе изменения из исходного проекта, то появятся конфликты, которые нужно будет разруливать и пытаться при этом не сломать деплой.
·>Не нужно, а можно. С Build/ — кстати, нельзя. Там, кстати, даже собсвенно делпоя я что-то не вижу. Там просто собирается zip, а где код заливки на сервер?
Подумай на досуге зачем в appveyor.yml написано:
nuget:
disable_publish_on_pr: true
·>В смысле внутри своей организации? Создашь job в своём CI и там передашь данные своей инфры через парамы/переменные окружения.
т.е. мне нужно оставить в pom.xml куски чужой инфраструктуры, чтобы потом у себя в CI это перегружать, а локально у меня просто по mvn deploy так же ничего не работало?
·>Они могут полезть. И не только в этом файле, но и в любой части исходников. И не потому что у тебя другая инфра, а потому что форк.
Ну и зачем мне лишние конфликты из-за изменения инфраструктуры, которые перемешаются с конфликтами из-за изменения кода?
Здравствуйте, karbofos42, Вы писали:
K>·>Чтобы код был проще. Сделаешь людям добро. K>Так ты за них переживаешь, вот научи как делать правильно и без скриптов или напиши универсальные скрипты, которые всем помогут
Ты просто критикуешь что они наворотили, но не показыавешь а как же надо. Собственно как надо — я и пытаюсь разобраться.
K>·>Но не как надо, поэтому им пришлось писать скрипты. K>Так у них там workingDir — это вообще не та папка, куда MSBuild собирает. K>Не нравится им из bin/Release файлы собирать, вот таскают туда, потом вручную очищают. K>Могли просто OutputPath переназначить при вызове dotnet build
Ок. Покажи образцово-показательую либу что-ли, как надо делать-то?
K>·>Но почему-то к тому мавену прикопался, что он якобы не делает ненужную очистку. Если тебе так хочется с очисткой, то "mvn clean deploy". K>Где я прикопался? Ты тут строки сравниваешь, вот тогда сравнивай весь функционал.
Так я и сравнил. В pom.xml его даже немного больше.
K>И в какую папку он всё соберёт, этот твой mvn? В target? Где кроме jar будет ещё куча папок? K>А где перенос в нужную workingDir только нужного?
Чего нужного? Не понял. И зачем что-то куда-то переносить? Функциональная цель какая?
K>·>Зоопарк в том как номера версий генерить — т.к. дело вкуса по сути. K>·>Ну и ещё сложности возникают в том, что иногда бывает сложно решить, что же собственно считать версией системы — она может состоять из многих компонент, в том числе динамически подгружаемых. K>Вот так новость
Ага, прикинь. Не все пишут cd-ejectors с About-диалогом.
K>У меня так null получается, хотя в META-INF/MANIFEST.MF версия прописана.
У тебя null получается, наверное потому, что jar-ки нет? Как без сборки узнать версию сборки? Хм. Хороший вопрос.
K>И не только у меня руки кривые, там в комментариях у народа так же null.
Там написано.
K>В итоге надо в application.yml добавить какой-нибудь конфиг, в него записать @project.version@, а потом его уже читать.
Не надо.
K>Очень удобно, в одну строку и никаких потенциальных ошибок.
Да, верно.
K>·>Там не только скачивание. Ты опять половину проигнорировал. K>Если убрать скрипты, которые делают то, что не делает maven, то там останется не так уж много, чтобы из-за этого переживать.
А конкретно, что можно убрать? Строки покажи.
K>·>Нужно. Если ты не обратил внимание, там ещё есть .appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy". K>Чем соответствует? mvn deploy автоматически вызывается на билд-сервере для указанных там веток?
"ps Build\runbuild.ps1" ≈ "mvn deploy"
K>·>Кто в принципе захочет делать деплой. K>Ну, у меня на компе нужные инструменты есть, мне большинство этих скриптов не нужно
Скрипты вызывают инструменты в нужном порядке с нужными аргументами.
K>·>Ну и "runbuild.ps1" не работает без "image: Visual Studio 2017". Чё сказать-то хотел? K>Врёшь же. У меня нет Visual Studio 2017 и скрипт почему-то запустился и отработал. K>Вот даже SDK нужный скачал
Круто. Достижение. А деплой-то отработал с подписью? Это то что ты пытался сделать с pom.xml.
K>·>Угу. Верно, эти скрипты делают ровно то же, что и pom.xml. И тоже не работают без окружения в виде "environment: VisualStudioVersion: 15.0". Чё сказать-то хотел? K>Покажешь где требование к такому окружению есть?
В .appveyor.yml
K>·>Как же надо делать-то сейчас? K>Кому как нравится. Я тебе привёл пример библиотек без кучи скриптов, но тебе не понравилось.
Я показал для каждой библиотеки где там скрипты. У первой аж целый отдельный репо скриптов был.
K>Кто хочет — может всё в csproj засунуть и будет то же самое, что с pom.xml, даже функциональнее.
Ага. Вот только почему-то никто не хочет.
K>·>Чтобы посмотреть как она выглядит. Или читать из соседнего проекта. Да тупо банально проверить что она таки собирается перед коммитом. K>т.е. когда в десктопном приложении ты изменишь надпись на кнопке или поменяешь разметку страницы, возвращаемой сервером, то билдишь документацию и перепроверяешь не поломалась ли она?
Хотсвопаю в IDE и смотрю результат через секунду.
IDE тоже открывает вот ровно тот же pom.xml и подхватывает структуру проекта.
K>·>В том, что реальный билд делается вот такой командой: K>·>
K>·>Чем она отличается от "dotnet build" и чем в принципе может отличаться я разбираться не хочу, совершенно. Факт, в том, что она уже отличается и это потенциальный источник ошибок. K>·>А вот "mvn package" делает ровно то же, что и "mvn deploy" до той же фазы. K>Реальный билд делается сильно короче, а тут прописывается версия, ИД пакета, подпись.
Угу. Всё то, что уже в pom.xml есть.
K>mvn package твой так же потребует всё это передавать, если будет нужно версию снаружи получать, профиль сборки и т.д.
Нет, не потребует.
K>В прошлом сообщении ты оправдывал наличие CI тем, что там только параметры для сборки передаются, теперь рассказываешь, что их якобы не надо передавать.
Не абстрактные "параметры сборки", а конкретно пароли и секреты. В строчке выше только это $signKeyPath можно как-то обосновать. Остальное — треш, а credentials для сервера вообще неясно где.
K>Чтобы mavn package не отличался от mvn deploy, им нужно одинаковые параметры на вход передавать и примерно такая же команда будет.
Не фантазируй.
K>·>Именно это тебе скорее всего может понадобиться. Но дотнет не умеет, вот и приходится извращаться. K>Зачем оно мне надо? Если у меня приложение под .NET FW 2.0, то мне NuGet пришлёт нужную сборку. Зачем мне тащить к себе огромную библиотеку, которая будет содержать код для нескольких версий рантайма?
Ты соберёшь с этой библиотекой своё приложение и отдашь пользователям. Пользователи могут запускать твоё приложение под разным рантаймом и подходящий код будет автоматически выбираться.
А если твоё приложение работает _только_ под .NET FW 2.0, то в топку такое приложение.
K>Чтобы моё приложение солиднее выглядело из-за объёма?
Отличие в коде как правило минимально. Только те классы, которые зависят от рантайма — будут разными. А если у библиотеки совсем всё разное, то уж проще сдеать два разных проекта.
K>·>Я так и не понял зачем. K>А ты себе скачиваешь приложения для всего подряд? Ну, чтобы и на x86, x64 и arm работало? А то вдруг железо поменяешь, надо, чтобы на любом запускалось?
Ну в java такой проблемы нет. Там же bytecode, платформа одна — VM. На другом железе будет только другая JRE. Приложение то же самое.
K>·>У него, наверняка, будет идентичный байткод. Только сигнатура версии будет другая. Я что-то не могу с ходу придумать что в принципе может отличаться... K>Ну, если написать код с использованием Virtual Threads, то он будет работать на 1.8 ?
Какой-то неудачный пример ты привёл для обоснования своей точки зрения. Если я пишу с расчётом на VT, то это будет совсем другая архитектура всего приложения — будет запускаться тысячи тредов. На 1.8 оно просто не потянет. А если я пишу VT с расчётом на 1.8 и кучу тредов не создаю, то отличие в коде будет лишь в ThreadFactory, одно булево значение — виртуальные треды создавать или реальные.
K>·>Но это лирика. Если тебе действительно захочется так сделать из любви к искусству, то просто пишешь либо два модуля с одним и тем же src но разным конфигом maven-compiler-plugin, либо можно сделать исполнение плагина дважды в одном модуле с разным out-dir. Потом собрать две jar-ки из этого. K>в общем, сложно и неудобно.
А конкретно, что тебя не устраивает? Это несколько строк конфигурации по сути — указать где что лежит и какой версии.
K>·>В смысле что-то типа условной компиляции как в C? #ifdef? Такого нет, и уверен, что не будет, слишком бессмысленное и беспощадное решение. Multiplatform как у тебя выше по ссылке — имеет смысл. Минимальная единица компиляции — класс. Те части методов, которые отличаются выносятся в отдельный класс. K>А по-моему удобная вещь, когда нужно поддерживать разные варианты сборки.
Ну это ты из мира C, в java это просто не нужно. В редких случаях какие-то системные штуки только от силы.
K>·>Для твоего случая с Async это и не нужно. Проще класс добавить в ту же сборку. Клиенты со старой версией не смогут его всё равно использовать. Зато просто проапгрейдя версию платформы, сразу будут иметь и этот класс. K>Зачем мне с собой таскать код, который не могу вызывать?
Можешь, если этот же код запустишь на другом рантайме.
K>·>CI нужны для автоматической сборки: триггер на изменение в гите, запуск билда, уведомления по емейлу, проверка пулл-реквестов, рисование отчётов и т.п. K>Ты в этом же сообщении чуть выше утверждал, что ".appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy""
Ну да. Тут ".appveyor.yml с "ps Build\runbuild.ps1", а там deployment.yml c "run: mvn --batch-mode deploy". И? Что сказать-то хотел?
K>·>А ты почитай с чего спор начинался. K>·>Не понял. А как ещё по-твоему на компе код проекта появиться может? K>Ну, я вот с github скачал zip-архив и распаковал.
Тогда у тебя будет чистая дира изначально.
K>Я тебе сразу говорил, что pom.xml в таком виде говно, т.к. придётся переписывать в нём репозитории и править под свою инфраструктуру. Если мне не нужна подпись, то я уберу просто этот блок из pom.xml,
Ну я говорю, что у тебя руки кривые. Не надо так делать.
K>а не буду кучу параметров прокидывать.
"Куча" это аж целых один или два?
K>В итоге из рабочего остаётся только билд, а деплой нужно весь переделывать под то, что мне будет нужно.
Ты не выдумывай. Ты давай конкретно строчки укажи которые действительно _надо_ менять? (Внимание: "надо", а не "тебе так хочется")
K>·>Да, примерно. И мавен ставить тоже необязательно. Если установка мавена тебя парит — используй mvnw. K>Ну, а скрипт на powershell скачиваешь .NET SDK и ему мавен никакой не нужен.
powershell зато теперь нужен.
K>·>Твоё утверждение было, что это лучше. Чем — ты секрет не раскрыл. K>·>Не лучше, хотя бы в том, что бинарик gradle весит несколько мегабайт. docker image и вся инфра для него — гигабайты. K>docker image один и в нём всё нужное будет. gradle — один из инструментов, который нужно будет ещё настраивать (прописывать в проекте для gradlew где искать этот самый gradle и загружать к себе)
Ну будешь условный gradle настраивать в docker image и иметь по docker image на каждую версию gradle. Какая разница-то? Инфра солиднее выглядит?
K>·>Каких? Ещё раз — jdk — единственный необходимый инструмент. K>А git ты откуда брать будешь, чтобы код репозитория подтянулся?
А ещё операционку мне надо. И компьютер. Да и вообще ты ж вроде любитель zip-файлы качать.
K>·>Пишется не скрипт для CI, а описание джобы в CI. Команда там одна "mvn deploy". K>Прямо такая "mvn deploy"? Или там для dev-сборки одна команда, для релиза — другая и в каждую куча параметров передаётся?
Да, такая.
K>·>Для msbuild — проще, верю. Для mvn — это тоже можно сделать, но это не проще. K>Ну, да. Проще каждую сборку окружение настраивать, чем один раз образ подготовить.
Я ещё раз говорю. Там не надо окружение настраивать. Нужет только jdk. Ок, можешь образ с jdk сделать, если так хочется. И это всё. А дальше "mvnw deploy" если и мавен не хочешь ставить.
K>·>"mvn compile", если ты вдруг почему-то IDE не хочешь использовать. K>Выполнил, не могу найти jar-файл.
А зачем он тебе?
K>·>Да пофиг на 1.6. K>Ну, мне и на .NET FW 2.0 пофиг
Вот и договорились.
K>·>Будет работать и на другой инфре, если у тебя есть права. В отличие от Build/, на который у тебя, внезапно, тоже прав нет. K>Как он будет работать, если у меня другие адреса и способ подписания будут?
Укажешь другие адреса и другой ключ подписания в инфре.
K>Сам проанализирует инфраструктуру и подстроится
А Build/ сам проанализирует что-ли?
K>или мне нужно будет переписывать pom.xml под свои нужды?
Нет, не нужно.
K>·>Тут не в Java не сделали, а разработчик не сделал в этом конкретном проекте — ибо это вообще никому не нужно. K>А почему когда что-то только в Newtonsoft.Json сделано, ты выдаёшь за аргумент, что значит в .NET так все вынуждены делать?
Покажи как надо.
K>·>И задеплоить на свой внутренний сервер nuget например для коллег? K>Да. Придётся правда пересилить себя и написать целую одну команду: nuget push
Как оно доки подхватит, например? Откуда оно возьмёт вот это всё? "/p:AdditionalConstants=$additionalConstants" "/p:GeneratePackageOnBuild=$buildNuGet" "/p:ContinuousIntegrationBuild=true" "/p:PackageId=$packageId" "/p:VersionPrefix=$majorWithReleaseVersion" "/p:VersionSuffix=$nugetPrerelease" "/p:AssemblyVersion=$assemblyVersion" "/p:FileVersion=$version" "/m"
K>·>Похоже таки первое. Ок. Разжую. K>·>Этот файлик "gradlew" пишется одной строчкой "gradle wrapper". ОДНА СТРОЧКА КОДА требуется от девелопера. Что эта строчка кода создаёт некий файлик определённого размера — интересует только тебя. K>·>Я тебе страшную вещь ещё скажу. Эта же строчка генерит и "gradle/wrapper/gradle-wrapper.jar" — загляни туда и представь как бедные java-девелоперы всю ночь это набивают в hex-редакторе по бумажке. K>Причём тут gradle и что он делает?
Ты спросил gradlew вот "зубодробительные скрипты" или всё нормально?, я ответил, что это автогенерённый файл и вообще можно удалить, добавлено исключительно для комфорта. В отличие от Build/ & co — вручную написанное и необходимое для функционирования проекта.
K>Файл gradlew.bat меньше, чем файл gradlew, значит команды батника мощнее и круче, т.к. позволяют то же самое делать меньшим числом строк.
Нет, не значит.
K>·>Мде. Ок. Попробую с другой стороны. Эти файлы ты можешь смело удалить из проекта: "rm -r *gradle*". Ничего не изменится. Вообще. K>Так командная строка винды круче линуксовой, т.к. меньше строк кода удалить нужно, чтобы они продолжали быть бесполезными?
Что за бред? Удаляй смело и gradlew, и gradlew.bat. Это чисто эстетическая штука.
K>Кстати, расскажи разработчикам этого скрипта и jar, что они сделали никому ненужную фигню.
Она нужна для любителей gradle. А не для этого конкретного проекта.
K>·>Чё? K>Ну, тут несколько примеров на Java было и у всех разный деплой, а ты говоришь, что "Ну что он разный — это ты сам придумал"
Ты о чём? Где что разный?
K>·>ms/facebook/google так и делают афаир. K>·>Ты не понял. Этот файл один на весь мир. Например, "skip gpg maven plugin" — будет первый резульат в гугле, ответ найдёшь за 5 секунд. K>Какой файл один на весь мир? pom.xml с кучей репозиториев на все случи жизни?
Такой, что дока доступна публично. В случае Build/ — в каждом конкретном случае приходится разбираться как и где что подписывается.
.>>А как отключить подписывание в Newtonsoft.Json? А в каждой из перечисленных тобой выше по топику либ? K>Не вызывать скрипт подписания. В других либах по-моему не во всех вообще подпись была, я не смотрел.
Как его не вызывать-то?
K>·>Я написал, что он функционально соответствует Build/ и т.д. K>А я тебе написал, что не соответствует и указал чем.
Перечисли по пунктам.
K>·>В Build/ тоже всякая хрень прописана. В том числе и абсолютный путь C:\ до файла с подписью. Которой, внезапно у тебя тоже нет. И быть не может. K>Так мне эта папка и не нужна. Я её выкину и сделаю свой деплой.
Именно. Ты выкинешь пару тысяч строк и напишешь свои, пусть несколько сотен. И это будет само по себе больше, чем две сотни в pom.xml на всё про всё.
K>С pom.xml тоже нужно будет всё под себя делать, но не получится выкинуть что-то отдельное, а придётся ковырять куски проекта.
Не нужно. Вот открой файл и укажи какие строчки ты хочешь менять и зачем.
K>Потом когда через год я захочу влить к себе изменения из исходного проекта, то появятся конфликты, которые нужно будет разруливать и пытаться при этом не сломать деплой.
А в случае Build/ — тебе придётся смотреть какие изменения были в этой выкинутой папочке, какие там ещё AdditionalConstants были когда добавлены и разбираться как перенести их в твой AnotherBuild/.
K>·>Не нужно, а можно. С Build/ — кстати, нельзя. Там, кстати, даже собсвенно делпоя я что-то не вижу. Там просто собирается zip, а где код заливки на сервер? K>Подумай на досуге зачем в appveyor.yml написано: K> disable_publish_on_pr: true
Мда... Т.е. весь этот твой Build/ и деплоить даже оказывается не умеет? Ну так это значит аналог только "mvn install" в лучшем случае. Что ты тут тогда с credentials выёживаешься — вообще неясно.
K>·>В смысле внутри своей организации? Создашь job в своём CI и там передашь данные своей инфры через парамы/переменные окружения. K>т.е. мне нужно оставить в pom.xml куски чужой инфраструктуры, чтобы потом у себя в CI это перегружать, а локально у меня просто по mvn deploy так же ничего не работало?
Там этой инфраструктуры — три строки от силы. И меняться будет раз в никогда.
K>·>Они могут полезть. И не только в этом файле, но и в любой части исходников. И не потому что у тебя другая инфра, а потому что форк. K>Ну и зачем мне лишние конфликты из-за изменения инфраструктуры, которые перемешаются с конфликтами из-за изменения кода?
Конфликты будут, если только и там будут изменения.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
K>>·>В смысле что-то типа условной компиляции как в C? #ifdef? Такого нет, и уверен, что не будет, слишком бессмысленное и беспощадное решение. Multiplatform как у тебя выше по ссылке — имеет смысл. Минимальная единица компиляции — класс. Те части методов, которые отличаются выносятся в отдельный класс. K>>А по-моему удобная вещь, когда нужно поддерживать разные варианты сборки. ·>Ну это ты из мира C, в java это просто не нужно. В редких случаях какие-то системные штуки только от силы.
Мир ява на андроиде сильно отстает от мира явы на том же сервере или десктопе. А если учесть, что основная масса это андроид, то получается, что это два разных мира. Как Java 8 поддерживается в Android
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Мир ява на андроиде сильно отстает от мира явы на том же сервере или десктопе. А если учесть, что основная масса это андроид, то получается, что это два разных мира. S>Как Java 8 поддерживается в Android
Это ты отстаёшь. Этой статье 5 лет. Сейчас уже java 11 повсеместно. И 17 местами.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты просто критикуешь что они наворотили, но не показыавешь а как же надо. Собственно как надо — я и пытаюсь разобраться.
Это ты критикуешь библиотеку и её подход к деплою.
·>Ок. Покажи образцово-показательую либу что-ли, как надо делать-то?
Так каждый делает как ему удобно и надо.
Я тебе несколько примеров привёл, где нет такого обилия скриптов, но тебе опять не понравилось.
Причём наличие файлов для деплоя в github у Java библиотеке тебе норм, а когда примерно то же самое для .NET сделано — это прибито гвоздями и никуда не годится.
·>Чего нужного? Не понял. И зачем что-то куда-то переносить? Функциональная цель какая?
Ну, в скриптах Newtonsoft.Json есть перенос скомпилированных файлов в отдельную рабочую папку и предварительная очистка этой папки.
Вот так они захотели и реализовали в виде скриптов.
В pom.xml такой функционал есть?
·>Ага, прикинь. Не все пишут cd-ejectors с About-диалогом.
А чего плохого в About-диалогах? Или крутые разработчики не сообщают пользователям версию ПО?
·>У тебя null получается, наверное потому, что jar-ки нет? Как без сборки узнать версию сборки? Хм. Хороший вопрос.
Прикинь, у меня всё собирается в единый jar-файл и даже запись с номером версии в манифесте внутри него имеется, а твой код возвращает null.
·>Там написано.
Что написано?
·>Не надо.
Ну, это единственный вариант, который сработал.
·>А конкретно, что можно убрать? Строки покажи.
Я тебе уже 10 раз это писал, сам сиди по строкам это высматривай, если хочется.
·>"ps Build\runbuild.ps1" ≈ "mvn deploy"
Определись уже "ровно то" или "≈"
·>Круто. Достижение. А деплой-то отработал с подписью? Это то что ты пытался сделать с pom.xml.
А должен был? Это ты мне обещал, что в pom.xml есть готовый деплой и он будет работать,
а потом начались нюансы, что подпись надо отключить, репозиторий переписать, т.е. выкинуть весь деплой и сделать заново.
·>В .appveyor.yml
У меня собирается без этого. Покажешь где в скриптах эта переменная окружения используется?
·>Я показал для каждой библиотеки где там скрипты. У первой аж целый отдельный репо скриптов был.
"целый отдельный репо скриптов" — это папка с несколькими yml для CI github.
Примерно такая же есть у твоей любимой библиотеки на Java, но там это естественно не считается
·>Хотсвопаю в IDE и смотрю результат через секунду. ·>IDE тоже открывает вот ровно тот же pom.xml и подхватывает структуру проекта.
А как же сборка документации, прогон тестов и вот это всё?
·>Угу. Всё то, что уже в pom.xml есть.
Только половины там нет
·>Нет, не потребует.
А что же для сборки под 1.6 там передаётся в CI?
·>Не абстрактные "параметры сборки", а конкретно пароли и секреты. В строчке выше только это $signKeyPath можно как-то обосновать. Остальное — треш, а credentials для сервера вообще неясно где.
А target — это пароль или секрет?
·>Ты соберёшь с этой библиотекой своё приложение и отдашь пользователям. Пользователи могут запускать твоё приложение под разным рантаймом и подходящий код будет автоматически выбираться. ·>А если твоё приложение работает _только_ под .NET FW 2.0, то в топку такое приложение.
Я соберу своё приложение под .NET FW 2.0 и оно будет работать на .NET FW 2.0 и выше (например, на 3.5), а не только на 2.0.
·>Отличие в коде как правило минимально. Только те классы, которые зависят от рантайма — будут разными. А если у библиотеки совсем всё разное, то уж проще сдеать два разных проекта.
два разных проекта, два разных pom.xml, две разных CI — это всё безусловно удобнее, чем просто собирать один и тот же проект под разные версии.
·>Ну в java такой проблемы нет. Там же bytecode, платформа одна — VM. На другом железе будет только другая JRE. Приложение то же самое.
Нативные библиотеки не используются? Ну, там sqlite какой?
·>Какой-то неудачный пример ты привёл для обоснования своей точки зрения. Если я пишу с расчётом на VT, то это будет совсем другая архитектура всего приложения — будет запускаться тысячи тредов. На 1.8 оно просто не потянет. А если я пишу VT с расчётом на 1.8 и кучу тредов не создаю, то отличие в коде будет лишь в ThreadFactory, одно булево значение — виртуальные треды создавать или реальные.
Ну, Future<> в старых версиях нет и где-то может захотеться их использовать. Это пойдёт или опять плохой пример?
·>А конкретно, что тебя не устраивает? Это несколько строк конфигурации по сути — указать где что лежит и какой версии.
Несколько строк конфигурации, дублировать несколько файлов и структур каталогов.
Собственно понятно почему наверно до сих пор куча людей сидит на 8 версии и не спешат обновляться.
·>Ну да. Тут ".appveyor.yml с "ps Build\runbuild.ps1", а там deployment.yml c "run: mvn --batch-mode deploy". И? Что сказать-то хотел?
Откуда взялся deployment.yml, если ты про mvn deploy говорил?
т.е. нагло наврал, что ".appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy"" и для равенства ещё нужно CI и для неё yml?
·>Тогда у тебя будет чистая дира изначально.
Так после сборки она не будет пустой, а git нет, чтобы вызвать git clean
·>Ну я говорю, что у тебя руки кривые. Не надо так делать.
А как надо? Оставить в файле чужой репозиторий? А как на своей инфраструктуре это всё разворачивать?
·>"Куча" это аж целых один или два?
Только для репозитория там будет как минимум адрес, имя токена и токен. Для подписи ещё добавятся, а там и ещё что-нибудь всплывёт.
·>Ты не выдумывай. Ты давай конкретно строчки укажи которые действительно _надо_ менять? (Внимание: "надо", а не "тебе так хочется")
Параметры репозитория деплоя, используемый плагин для подписи — это то, что я помню. Сам по этому файлу ищи какие строчки и что там ещё от инфраструктуры есть.
·>powershell зато теперь нужен.
Так он есть изначально при установке винды, а деплой заведомо будет на винде делаться, т.к. там .NET FW фигурирует, а не только .NET
·>А ещё операционку мне надо. И компьютер. Да и вообще ты ж вроде любитель zip-файлы качать.
т.е. ты наврал, что "jdk — единственный необходимый инструмент"? А нужную версию git кто будет устанавливать? Есть стандартный скрипт gitw, который это сделает?
·>Да, такая.
И как mvn deploy узнает когда нужно выполнить деплой тестовой версии, а когда — релиз?
·>Я ещё раз говорю. Там не надо окружение настраивать. Нужет только jdk. Ок, можешь образ с jdk сделать, если так хочется. И это всё. А дальше "mvnw deploy" если и мавен не хочешь ставить.
Сам же пишешь выше, что ещё компьютер нужен
·>А зачем он тебе?
Так я говорил, что для отключения тестов нужно вызвать сборку с ключом "maven.test.skip=true", а ты сказал, что mvn compile делает то же самое, но тесты не нужно будет отключать.
Внезапно оказалось, что разница есть.
Опять когда что-то не вписывается, то начинается, что и не надо?
·>Укажешь другие адреса и другой ключ подписания в инфре.
Так я может не хочу ничего подписывать или захочу другим плагином.
Что в итоге от этого чужого деплоя останется?
·>А Build/ сам проанализирует что-ли?
Так он там ищет всякое, если не находит, то скачивает.
·>Нет, не нужно.
т.е. нужно оставить там чужой репозиторий для деплоя и чужую подпись, доступа к которым у меня нет и не будет?
·>Как оно доки подхватит, например? Откуда оно возьмёт вот это всё? "/p:AdditionalConstants=$additionalConstants" "/p:GeneratePackageOnBuild=$buildNuGet" "/p:ContinuousIntegrationBuild=true" "/p:PackageId=$packageId" "/p:VersionPrefix=$majorWithReleaseVersion" "/p:VersionSuffix=$nugetPrerelease" "/p:AssemblyVersion=$assemblyVersion" "/p:FileVersion=$version" "/m"
Так мне не надо
·>Ты спросил gradlew вот "зубодробительные скрипты" или всё нормально?, я ответил, что это автогенерённый файл и вообще можно удалить, добавлено исключительно для комфорта. В отличие от Build/ & co — вручную написанное и необходимое для функционирования проекта.
Так речь не про gradle, а про gradlew vs gradlew.bat
·>Нет, не значит.
Значит pom.xml хуже, чем набор csproj, yml, ps1, т.к. в нём меньше строк?
·>Она нужна для любителей gradle. А не для этого конкретного проекта.
Нет. Раз она находится в проекте, значит её автор был вынужден её добавить.
Не говоря о том, что бедолаге приходится и gradle и maven поддерживать.
·>Ты о чём? Где что разный?
Цитирую:
И смотрим на pom.xml — ровно 200 строк на всё, притом жутко избыточный xml. Весь билд с зависимостями, с доками, с тестами, с подписью, деплойментом, инфой о лицензии, разработчиках, параграф readme и т.п. И заработает в куче разных IDE на куче разных OS.
Вот Gson 528 строк, чуть посложнее, но там кода больше, несколько модулей, перформанс тесты, проверка стиля, обфускация, манипуляция с гит-репой, метрики всякие.
И это только то, что в xml, а есть ещё CI.
·>Такой, что дока доступна публично. В случае Build/ — в каждом конкретном случае приходится разбираться как и где что подписывается.
Так же как в yml для CI все пишут разное и в этом приходится разбираться.
·>Как его не вызывать-то?
Ну, не вызываешь скрипт Sign-Package.ps1 и не подписываешь пакет.
·>Перечисли по пунктам.
Я уже 10 раз повторял
·>Именно. Ты выкинешь пару тысяч строк и напишешь свои, пусть несколько сотен. И это будет само по себе больше, чем две сотни в pom.xml на всё про всё.
Я их выкину и напишу небольшие скрипты yml для какой-нибудь CI, зато не буду менять исходный проект, а поменяю только деплой.
Строки никогда не считал.
·>Не нужно. Вот открой файл и укажи какие строчки ты хочешь менять и зачем.
Ладно. Уговорил.
24-28: scm
50-60: distributionManagement
138-157: maven-gpg-plugin
158-168: nexus-staging-maven-plugin
Итого сколько там? Больше 20% от файла на выброс?
·>А в случае Build/ — тебе придётся смотреть какие изменения были в этой выкинутой папочке, какие там ещё AdditionalConstants были когда добавлены и разбираться как перенести их в твой AnotherBuild/.
Не нужно.
·>Мда... Т.е. весь этот твой Build/ и деплоить даже оказывается не умеет? Ну так это значит аналог только "mvn install" в лучшем случае. Что ты тут тогда с credentials выёживаешься — вообще неясно.
С чего это он мой? Ты его сюда принёс и я его не писал.
У тебя сомнительное понимание слова "аналог".
·>Там этой инфраструктуры — три строки от силы. И меняться будет раз в никогда.
и зачем мне это держать в pom.xml, если это чужая инфраструктура?
:
