Здравствуйте, 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>·>

exec { & $script:msBuildPath "/t:build" "/v:$msbuildVerbosity" $projectPath "/p:Configuration=Release" "/p:LibraryFrameworks=`"$libraryFrameworks`"" "/p:TestFrameworks=`"$testFrameworks`"" "/p:AssemblyOriginatorKeyFile=$signKeyPath" "/p:SignAssembly=$signAssemblies" "/p:TreatWarningsAsErrors=$treatWarningsAsErrors" "/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>·>Чем она отличается от "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>Ну и зачем мне лишние конфликты из-за изменения инфраструктуры, которые перемешаются с конфликтами из-за изменения кода?
Конфликты будут, если только и там будут изменения.