Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>> Мир ява на андроиде сильно отстает от мира явы на том же сервере или десктопе. А если учесть, что основная масса это андроид, то получается, что это два разных мира. S>>Как Java 8 поддерживается в Android ·>Это ты отстаёшь. Этой статье 5 лет. Сейчас уже java 11 повсеместно. И 17 местами.
Во во. А какая последняя? 21. Ну вот хочется то 21, но нужно поддерживать 11 и minSdk 19, так как нужно поддерживать разные версии андроидов.
Опять же на разных версиях андроида и различные вызовы (if(Build.VERSION.SDK_INT >= ). Но мы можем иметь несколько версий проектов под разные платформы.
В большинстве случаев используются разные проекты, но с единым набором файлов. Там, где нельзя в каких то местах использовать 21, просто пишется #ifdef
Мало того, та же графика на винде, андроиде и линкусе разная. Есть кроссплатформенные библиотеки, но на них отображаются те же шрифты сильно по разному.
Ну и прочие нюансы отображения.
Вот почему графика на Java на винде это вырви глаз.
В основном код общий, но вызов отрисовки немного различный и можно привести максимально близкое отображение.
И здесь помогает условная компиляция.
Я её применяю постоянно! В винде тоже зоопарк. Начиная от компакт фреймворк, штуки 4 основных фреймворка. Ну и .Net Core
В большинстве случаев код одинаковый, но есть нюансы. И вот здесь #ifdef в помощь.
и солнце б утром не вставало, когда бы не было меня
More than 56% of applications are now using Java 11 in production (up from 48% in 2022 and 11% in 2020). Java 8 is a close second with nearly 33% of applications using it in production (down from 46% in 2022).
While Java 11 has held the top spot for two years in a row, the adoption rate of Java 17 far exceeds what the developer world saw when Java 11 was introduced. More than 9% of applications are now using Java 17 in production (up from less than 1% in 2022), representing a 430% growth rate in one year. It took years for Java 11 to reach anywhere near that level.
56% java 11 — это повсеместно
9% java 17 — это местами
почти 33% java 8 — это нигде не используется или как назовём?
Либо на Java пишут одни ретрограды, либо переход на новые версии приносит больше проблем, чем пользы.
Иначе непонятно почему люди не пользуются современными возможностями платформы и сидят на старом, снятом с поддержки.
Я так понимаю, что Oracle даже продлили "Extended Support" до 2030 года, потому что никому 8 версия не нужна: https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Здравствуйте, flаt, Вы писали:
F>Понятно, что у возможностей GUI есть предел, и GUI обёртки над wget/curl выглядят откровенно нелепо (потому что UI нужно уметь проектировать) и ненужно (потому что "wget http://host.com/file.txt" легко запомнить и легко написать)
В корне не согласен. Если подумать, GUI всегда можно сделать намного лучше конфигов/командных строк (но, как справедливо отмечено, UI нужно уметь проектировать).
Возьмём пример с wget. Я им не пользуюсь (а чтобы проектировать хороший UI, юз-кейсы надо понимать от и до), поэтому рассматриваю просто как абстрактный инструмент обработки URL, и прошу не придираться. Знал бы сценарии, предложил бы что-нибудь ещё лучше.
Как подойдёт к написанию подобного GUI дурак переученный бэкендер? Вот вам однострочное поле ввода, наслаждайтесь. А гуишник видит широкое поле для улучшений:
• Можно сделать подсказки заполнения на основе существования реальных сайтов. Вводишь y, он предлагает yadi.sk, yahoo.com и т.д. Придумать, как это сделать бесплатно, без СМС и регистрации, и не храня локально БД актуальных адресов, и не делая лишних запросов к целевому сайту — оставляю читателю в качестве домашнего задания (подсказка: подумайте, где ещё бывает автозаполнение).
• К подсказкам заполнения можно примешивать секцию recent queries. Система ниппель: один раз ввёл адрес, копировать в блокнот больше не надо, повторно вводить не надо, перевыкачивай сколько хочешь (пока не удалишь из history).
• URL можно поверять на соответствие стандарту, и если ввод адреса — часть какой-то формы, то не давать сохранять конфиг, пока не будет введён валидный адрес. Чтобы wget потом в рантайме не ёк. Когда фокус внимания на вводе URL, а окошко ругается, понять, где ошибка, сравнительно просто (особенно если объяснить, какая часть какого RFC нарушена). Когда wget начнёт ругаться на то же самое в рамках сложного процесса, частью которого он является, найти по логам, что ошибка была в невалидности URL'я, намного сложнее.
• URL можно проверять на безопасность (список критериев проверки надо попросить у специалистов по ИБ своей компании).
• Схему (http, https, ftp, может, ещё что-то) можно давать выбирать из списка. Мелочь, а приятно. (Главное, сделать это так, чтобы это не были две отдельных строки, иначе будут проблемы со вставкой из буфера — но это и дураку понятно).
Здравствуйте, karbofos42, Вы писали:
K>56% java 11 — это повсеместно K>9% java 17 — это местами K>почти 33% java 8 — это нигде не используется или как назовём?
Т.е. 98% это java 8+. В статье было "java 8 нигде не работает".
K>Либо на Java пишут одни ретрограды, либо переход на новые версии приносит больше проблем, чем пользы.
Либо это ложная дилемма.
K>Иначе непонятно почему люди не пользуются современными возможностями платформы и сидят на старом, снятом с поддержки.
Можно используя JDK21 компилять с target=8.
K>Я так понимаю, что Oracle даже продлили "Extended Support" до 2030 года, потому что никому 8 версия не нужна: K>https://www.oracle.com/java/technologies/java-se-support-roadmap.html
google пилит свою jre для андроида и неохотно обновляется, ибо топит за свой родной Kotlin. Чисто политика.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
S>·>Это ты отстаёшь. Этой статье 5 лет. Сейчас уже java 11 повсеместно. И 17 местами. S>Во во. А какая последняя? 21. Ну вот хочется то 21, но нужно поддерживать 11 и minSdk 19, так как нужно поддерживать разные версии андроидов. S>Опять же на разных версиях андроида и различные вызовы (if(Build.VERSION.SDK_INT >= ). Но мы можем иметь несколько версий проектов под разные платформы. S>В большинстве случаев используются разные проекты, но с единым набором файлов. Там, где нельзя в каких то местах использовать 21, просто пишется #ifdef
#ifdef означает, что тебе придётся хостить десяток вариантов бинарей и перевытягивать их всех при любом изменении версии платформы. И это из-за разницы в нескольких строках кода.
S> Мало того, та же графика на винде, андроиде и линкусе разная. Есть кроссплатформенные библиотеки, но на них отображаются те же шрифты сильно по разному. S>Ну и прочие нюансы отображения. S> Вот почему графика на Java на винде это вырви глаз.
Зависит от приложения. Скачай какой-нибдуь Jetbrains — где там что не так?
S>В основном код общий, но вызов отрисовки немного различный и можно привести максимально близкое отображение. S>И здесь помогает условная компиляция.
Не единственно верное решение. В java просто делаются разные имплементации и используются разные зависимости.
S> Я её применяю постоянно! В винде тоже зоопарк. Начиная от компакт фреймворк, штуки 4 основных фреймворка. Ну и .Net Core S>В большинстве случаев код одинаковый, но есть нюансы. И вот здесь #ifdef в помощь.
Могу только посочувствовать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Это ты отстаёшь. Этой статье 5 лет. Сейчас уже java 11 повсеместно. И 17 местами. S>>Во во. А какая последняя? 21. Ну вот хочется то 21, но нужно поддерживать 11 и minSdk 19, так как нужно поддерживать разные версии андроидов. S>>Опять же на разных версиях андроида и различные вызовы (if(Build.VERSION.SDK_INT >= ). Но мы можем иметь несколько версий проектов под разные платформы. S>>В большинстве случаев используются разные проекты, но с единым набором файлов. Там, где нельзя в каких то местах использовать 21, просто пишется #ifdef ·>#ifdef означает, что тебе придётся хостить десяток вариантов бинарей и перевытягивать их всех при любом изменении версии платформы. И это из-за разницы в нескольких строках кода.
Вопрос, что ты имеешь ввиду под версией платформы?
Например для андроида и сервера это разные проекты, но есть одни и те же файлы. Это модели и прочие утилиты. Для IOS тоже надо делать нативные проекты.
Для разного набора мин и макс версий андроида тоже. #ifdef говорит, что этот код только для конкретной платформы. В если я его поменял только для этой платформы, то компилить для других не надо. А если общий код, то конечно надо.
Конечно есть ньансы, когда надо, что то заменить через рефакторинг, то прочие #ifdef студия не видит.
S>> Мало того, та же графика на винде, андроиде и линкусе разная. Есть кроссплатформенные библиотеки, но на них отображаются те же шрифты сильно по разному. S>>Ну и прочие нюансы отображения. S>> Вот почему графика на Java на винде это вырви глаз. ·>Зависит от приложения. Скачай какой-нибдуь Jetbrains — где там что не так?
А есть Jetbrains под Android, IOS
На самом деле я пользуюсь Анроид студией и после VS как на 10 лет назад очутился.
S>>В основном код общий, но вызов отрисовки немного различный и можно привести максимально близкое отображение. S>>И здесь помогает условная компиляция. ·>Не единственно верное решение. В java просто делаются разные имплементации и используются разные зависимости.
Во во. То есть различные библиотеки которые нужно по разному компилить. И возвращаемся к условной компиляции S>> Я её применяю постоянно! В винде тоже зоопарк. Начиная от компакт фреймворк, штуки 4 основных фреймворка. Ну и .Net Core S>>В большинстве случаев код одинаковый, но есть нюансы. И вот здесь #ifdef в помощь. ·>Могу только посочувствовать.
Ну и Java тоже зоопарк. Код написаный для Андроида не запустится на Винде или IOS.
Мне вот интересно, что ты пишешь огромные простыни, на то, что по сути выеденного яйца не нужно для обсуждения.
Если, что то существует значит оно нужно и им пользуются. Если тебе это не нужно, не значит, что другим это не надо.
Про условную компиляцию добавлю, что я пишу код на последней версии C#. Если этот код не подходит для других платформ то смотрю, сколько мне нужно кода менять, и вероятность изменения этого кода. Тогда либо дроблю файлы, либо использую условную компиляцию.
Условная компиляция хороша тем, что я все меняю в одном месте, а не как иногда бывает в 4 местах.
Ну и #if DEBUG тоже помогает не менять файлы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, karbofos42, Вы писали:
K>·>Ты просто критикуешь что они наворотили, но не показыавешь а как же надо. Собственно как надо — я и пытаюсь разобраться. K>Это ты критикуешь библиотеку и её подход к деплою.
Не конкретную библиотеку, а доступный инструментарий и прочий msbuild.
K>·>Ок. Покажи образцово-показательую либу что-ли, как надо делать-то? K>Так каждый делает как ему удобно и надо.
Вот это я и критикую. Общего подхода нет. Скачиваешь какую-нибудь библиотеку и начинаешь разбираться кто как хитровывернулся. В java мире выкачиваешь — и оно работает с заранее известными командами. А если что-то хочешь поменять — просто гуглишь общую фразу, а не специфичную для данного проекта. Т.е. "как отключить gpg в maven", а не "как отключить signature в Newtonsoft.json".
K>Я тебе несколько примеров привёл, где нет такого обилия скриптов, но тебе опять не понравилось.
В каждом из твоих примеров скриптов было просто дофига. Просто они все разные и в разных местах, сделаны по-разному.
K>Причём наличие файлов для деплоя в github у Java библиотеке тебе норм, а когда примерно то же самое для .NET сделано — это прибито гвоздями и никуда не годится.
Это ты фантазируешь.
K>·>Чего нужного? Не понял. И зачем что-то куда-то переносить? Функциональная цель какая? K>Ну, в скриптах Newtonsoft.Json есть перенос скомпилированных файлов в отдельную рабочую папку и предварительная очистка этой папки.
Функциональная цель какая?
K>Вот так они захотели и реализовали в виде скриптов. K>В pom.xml такой функционал есть?
Эээ. Копировать файлы туда-сюда?.. Конечно.
K>·>Ага, прикинь. Не все пишут cd-ejectors с About-диалогом. K>А чего плохого в About-диалогах? Или крутые разработчики не сообщают пользователям версию ПО?
Не знаю. Я не вижу ничего плохого в About-диалогах.
K>·>У тебя null получается, наверное потому, что jar-ки нет? Как без сборки узнать версию сборки? Хм. Хороший вопрос. K>Прикинь, у меня всё собирается в единый jar-файл и даже запись с номером версии в манифесте внутри него имеется, а твой код возвращает null.
Ну руки значит кривые.
K>·>Там написано. K>Что написано?
Что, где, когда.
K>·>Не надо. K>Ну, это единственный вариант, который сработал.
Обратись к квалифицированным разработчикам за помощью.
K>Я тебе уже 10 раз это писал, сам сиди по строкам это высматривай, если хочется.
Это были твои личные фантазии, а не реальное положение вещей.
K>·>"ps Build\runbuild.ps1" ≈ "mvn deploy" K>Определись уже "ровно то" или "≈"
"ps Build\runbuild.ps1" < "mvn deploy", т.к. runbuild деплоить-то оказывается не умеет.
K>·>Круто. Достижение. А деплой-то отработал с подписью? Это то что ты пытался сделать с pom.xml. K>А должен был? Это ты мне обещал, что в pom.xml есть готовый деплой и он будет работать,
Да. И он прекрасно работает, просто для тебя он запрещён. Обратись к автору библиотеки (да-да, ты его найдёшь в том же pom.xml) и попроси права. Если он тебе разрешит, то и ты сможешь.
K>а потом начались нюансы, что подпись надо отключить, репозиторий переписать, т.е. выкинуть весь деплой и сделать заново.
Не надо. А можно. Либо отключить, либо сделать свою. Смотря что именно тебе _надо_ (а не просто хочется ради того, чтоб к чему прикопаться было).
K>·>В .appveyor.yml K>У меня собирается без этого.
А у меня не собирается:
$ pwsh Build\runbuild.ps1
Command 'pwsh' not found
ЧЯДНТ?
K> Покажешь где в скриптах эта переменная окружения используется?
Это ты показывай, что она лишняя. Я предположил, раз там написано, значит надо.
K>·>Я показал для каждой библиотеки где там скрипты. У первой аж целый отдельный репо скриптов был. K>"целый отдельный репо скриптов" — это папка с несколькими yml для CI github.
Угу, врунчую написанными, специально для этого проекта.
K>Примерно такая же есть у твоей любимой библиотеки на Java, но там это естественно не считается
Есть, но там для деплоя ровно один файл, 82 строки, включая комментарии. Ок, можешь считать что будет не 200 строк, а 300. Тебе легче?
В любом случае в показанных тобой либах — таких строк на порядки больше, причём делать они умеют меньше.
K>·>Хотсвопаю в IDE и смотрю результат через секунду. K>·>IDE тоже открывает вот ровно тот же pom.xml и подхватывает структуру проекта. K>А как же сборка документации, прогон тестов и вот это всё?
Ну если нужно, есть и кнопочка для этого.
K>·>Угу. Всё то, что уже в pom.xml есть. K>Только половины там нет
Какой?
K>·>Нет, не потребует. K>А что же для сборки под 1.6 там передаётся в CI?
Мы вроде договорились, что 1.6 никого не интересует... Но не важно. Сборка под 1.6 среди в том же .yml который 82 строки.
K>·>Не абстрактные "параметры сборки", а конкретно пароли и секреты. В строчке выше только это $signKeyPath можно как-то обосновать. Остальное — треш, а credentials для сервера вообще неясно где. K>А target — это пароль или секрет?
Нет.
K>·>Ты соберёшь с этой библиотекой своё приложение и отдашь пользователям. Пользователи могут запускать твоё приложение под разным рантаймом и подходящий код будет автоматически выбираться. K>·>А если твоё приложение работает _только_ под .NET FW 2.0, то в топку такое приложение. K>Я соберу своё приложение под .NET FW 2.0 и оно будет работать на .NET FW 2.0 и выше (например, на 3.5), а не только на 2.0.
Но не будет использовать возможности 3.5? Чем это хорошо?
K>·>Отличие в коде как правило минимально. Только те классы, которые зависят от рантайма — будут разными. А если у библиотеки совсем всё разное, то уж проще сдеать два разных проекта. K>два разных проекта, два разных pom.xml, две разных CI — это всё безусловно удобнее, чем просто собирать один и тот же проект под разные версии.
Это я исходил из предположения что совсем всё разное, т.е. два проекта. Пихать два набора исходников в одно место и разделять их потом через #ifdef — это уже совсем какое-то извращение.
Да даже в самом худшем случае у тебя будет условно не 300 строк, а 600. Всё равно меньше Build/.
K>·>Ну в java такой проблемы нет. Там же bytecode, платформа одна — VM. На другом железе будет только другая JRE. Приложение то же самое. K>Нативные библиотеки не используются?
Не понял. В нативных библиотеках нет java кода. Но в любом случае, практически не используются, зачем? А если используются, то они же отдельно собираются, своим отдельным тулчейном (если что в mvn есть плагины и для этого).
Нативную библиотеку можно запаковать внутрь jar как ресурс и подружать при запуске, выбирая платформу на ходу.
K> Ну, там sqlite какой?
h2db?
K>·>Какой-то неудачный пример ты привёл для обоснования своей точки зрения. Если я пишу с расчётом на VT, то это будет совсем другая архитектура всего приложения — будет запускаться тысячи тредов. На 1.8 оно просто не потянет. А если я пишу VT с расчётом на 1.8 и кучу тредов не создаю, то отличие в коде будет лишь в ThreadFactory, одно булево значение — виртуальные треды создавать или реальные. K>Ну, Future<> в старых версиях нет и где-то может захотеться их использовать. Это пойдёт или опять плохой пример?
Ну просто не сможешь вызвать метод с Future в сигнатуре. Ещё это нужно для транзитивного использования.
Библиотека AAA: использует фичи j11, но поддерживает j8.
Библиотека BBB: знает только j8, использует AAA.
Библиотека XXX: использует j11, зависит от BBB.
Библиотека YYY: использует j8, зависит от BBB.
Поэтому удобнее когда AAA содержит код и j11, и j8.
K>·>А конкретно, что тебя не устраивает? Это несколько строк конфигурации по сути — указать где что лежит и какой версии. K>Несколько строк конфигурации, дублировать несколько файлов и структур каталогов.
Зачем дублировать?
K>Собственно понятно почему наверно до сих пор куча людей сидит на 8 версии и не спешат обновляться.
Основная причина гораздо прозаичнее: "и так всё работает... зачем шевелиться?".
K>·>Ну да. Тут ".appveyor.yml с "ps Build\runbuild.ps1", а там deployment.yml c "run: mvn --batch-mode deploy". И? Что сказать-то хотел? K>Откуда взялся deployment.yml, если ты про mvn deploy говорил?
Внутри deployment.yml находится "mvn deploy".
K>т.е. нагло наврал, что ".appveyor.yml с "ps Build\runbuild.ps1", ровно то, что соответствует "mvn deploy"" и для равенства ещё нужно CI и для неё yml?
Наверное я неоднозначно выразился. Я имел в виду что строчка "ps Build\runbuild.ps1" в файле .appveyor.yml эквивалентна "mvn deploy". На самом деле я ошибся. Она эквивалентна "mvn install", т.к. даже деплоить она не умеет.
K>·>Тогда у тебя будет чистая дира изначально. K>Так после сборки она не будет пустой, а git нет, чтобы вызвать git clean
Ну "mvn clean" тогда.
K>·>Ну я говорю, что у тебя руки кривые. Не надо так делать. K>А как надо? Оставить в файле чужой репозиторий? А как на своей инфраструктуре это всё разворачивать?
Так это чужой проект. И там репозиторий какой надо, не надо его менять. Если ты решил стыритьпозаимствовать проект к себе, то да, поменяешь на свой. Заметь, это всего две строчки. А не две тысячи, как в случае с Build/.
Да, кстати, менять даже необязательно, можно положить рядом settings.xml с деталями твоей инфры. И это будет работать для большинства библиотек, которые ты решишь "позаимствовать" к себе. Тебе не надо разбираться с каждой индивидуально.
K>·>"Куча" это аж целых один или два? K>Только для репозитория там будет как минимум адрес, имя токена и токен.
Нет, в pom.xml токена нет. Там только адрес и имя (которое неясно зачем менять).
K>Для подписи ещё добавятся, а там и ещё что-нибудь всплывёт.
Это твои фантазии.
K>·>powershell зато теперь нужен. K>Так он есть изначально при установке винды, а деплой заведомо будет на винде делаться, т.к. там .NET FW фигурирует, а не только .NET
Печаль.
K>·>А ещё операционку мне надо. И компьютер. Да и вообще ты ж вроде любитель zip-файлы качать. K>т.е. ты наврал, что "jdk — единственный необходимый инструмент"? А нужную версию git кто будет устанавливать? Есть стандартный скрипт gitw, который это сделает?
git — обходимый инструмент. Ты мне тут сам про zip рассказывал.
K>·>Да, такая. K>И как mvn deploy узнает когда нужно выполнить деплой тестовой версии, а когда — релиз?
По номеру версии.
K>·>Я ещё раз говорю. Там не надо окружение настраивать. Нужет только jdk. Ок, можешь образ с jdk сделать, если так хочется. И это всё. А дальше "mvnw deploy" если и мавен не хочешь ставить. K>Сам же пишешь выше, что ещё компьютер нужен
Прям ужас.
K>·>А зачем он тебе? K>Так я говорил, что для отключения тестов нужно вызвать сборку с ключом "maven.test.skip=true", а ты сказал, что mvn compile делает то же самое, но тесты не нужно будет отключать. K>Внезапно оказалось, что разница есть. K>Опять когда что-то не вписывается, то начинается, что и не надо?
Я не знаю что ты хотел. Расскажи вначале про аналоги в Build/. Мы же функциональность сравниваем, а не просто твоё невежество обсуждаем. Как собирать с тестами|без тестов|етс?
K>·>Укажешь другие адреса и другой ключ подписания в инфре. K>Так я может не хочу ничего подписывать
Я тебе показал как это сделать. Одна опция в командную строку или или в твою инфру.
K>или захочу другим плагином.
Зачем?
K>Что в итоге от этого чужого деплоя останется?
Всё.
K>·>А Build/ сам проанализирует что-ли? K>Так он там ищет всякое, если не находит, то скачивает.
Что конкретно "всякое"? Ты требовал, что он "Сам проанализирует инфраструктуру и подстроится".
K>·>Нет, не нужно. K>т.е. нужно оставить там чужой репозиторий для деплоя и чужую подпись, доступа к которым у меня нет и не будет?
Да, чем оно тебе там мешает? Укажи свои детали в своей инфре.
K>·>Как оно доки подхватит, например? Откуда оно возьмёт вот это всё? "/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 вот "зубодробительные скрипты" или всё нормально?, я ответил, что это автогенерённый файл и вообще можно удалить, добавлено исключительно для комфорта. В отличие от Build/ & co — вручную написанное и необходимое для функционирования проекта. K>Так речь не про gradle, а про gradlew vs gradlew.bat
К чему эта речь?
K>·>Нет, не значит. K>Значит pom.xml хуже, чем набор csproj, yml, ps1, т.к. в нём меньше строк?
Нет, не значит.
K>·>Она нужна для любителей gradle. А не для этого конкретного проекта. K>Нет. Раз она находится в проекте, значит её автор был вынужден её добавить.
Нет, не вынужден. И добавил не автор либы, а кто-то другой, для личного комфорта.
K>Не говоря о том, что бедолаге приходится и gradle и maven поддерживать.
В чём эта "поддержка" заключается? Погляди историю этих gradlew и посчитай сколько раз они менялись.
K>·>Ты о чём? Где что разный? K>Цитирую: K>
K>И смотрим на pom.xml — ровно 200 строк на всё, притом жутко избыточный xml. Весь билд с зависимостями, с доками, с тестами, с подписью, деплойментом, инфой о лицензии, разработчиках, параграф readme и т.п. И заработает в куче разных IDE на куче разных OS.
K>Вот Gson 528 строк, чуть посложнее, но там кода больше, несколько модулей, перформанс тесты, проверка стиля, обфускация, манипуляция с гит-репой, метрики всякие.
K>И это только то, что в xml, а есть ещё CI.
Э. И? В Newtonsoft.Json тоже есть CI.
K>·>Такой, что дока доступна публично. В случае Build/ — в каждом конкретном случае приходится разбираться как и где что подписывается. K>Так же как в yml для CI все пишут разное и в этом приходится разбираться.
И? Какое это имеет отношение к "Build/,*csproj,*.sln..." vs "pom.xml"?
K>·>Как его не вызывать-то? K>Ну, не вызываешь скрипт Sign-Package.ps1 и не подписываешь пакет.
Команду в студию. "Собрать с подписью", "собрать без подписи". И где это нагуглить.
K>·>Перечисли по пунктам. K>Я уже 10 раз повторял
Я это 20 раз опроверг.
K>·>Именно. Ты выкинешь пару тысяч строк и напишешь свои, пусть несколько сотен. И это будет само по себе больше, чем две сотни в pom.xml на всё про всё. K>Я их выкину и напишу небольшие скрипты yml для какой-нибудь CI, зато не буду менять исходный проект, а поменяю только деплой. K>Строки никогда не считал.
Могу только позавидовать твоей трудолюбивости.
K>·>Не нужно. Вот открой файл и укажи какие строчки ты хочешь менять и зачем. K>Ладно. Уговорил. K>24-28: scm
Зачем?
K>50-60: distributionManagement
Зачем? В любом случае достаточно поменять максимум ДВЕ строчки 54 и 58.
K>138-157: maven-gpg-plugin
Зачем?
K>158-168: nexus-staging-maven-plugin
Зачем?
K>Итого сколько там?
Итого — достаточно поменять ноль строчек. В худшем случае — две.
K> Больше 20% от файла на выброс?
В случае Build/ — 100% на выброс.
K>·>А в случае Build/ — тебе придётся смотреть какие изменения были в этой выкинутой папочке, какие там ещё AdditionalConstants были когда добавлены и разбираться как перенести их в твой AnotherBuild/. K>Не нужно.
Почему ты так решил? На него ссылки есть из исходников. И в последствии что-то может быть добавлено ещё.
K>·>Мда... Т.е. весь этот твой Build/ и деплоить даже оказывается не умеет? Ну так это значит аналог только "mvn install" в лучшем случае. Что ты тут тогда с credentials выёживаешься — вообще неясно. K>С чего это он мой? Ты его сюда принёс и я его не писал. K>У тебя сомнительное понимание слова "аналог".
Ок, не твой и я весь такой сомнительный... А по сути есть чего?
K>·>Там этой инфраструктуры — три строки от силы. И меняться будет раз в никогда. K>и зачем мне это держать в pom.xml, если это чужая инфраструктура?
Так и проект чужой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
K>>56% java 11 — это повсеместно K>>9% java 17 — это местами K>>почти 33% java 8 — это нигде не используется или как назовём? ·>Т.е. 98% это java 8+. В статье было "java 8 нигде не работает".
А также 56 + 33 = 89% это те, что не выше Java 11
Как 17 протухнет достаточно, эти 89% промигрируют на нее
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Мир в принципе отказывается от XML дублируя все его стандарты в комплекте технологий Json.
+1
ЭФ>Какие идеи лежали в основе решения использовать XML?
Бывает, за решениями не стоит ничего, кроме "наши деды так делали". Официально будут петь дифирамбы про какой-то "интыпрайз стандарт", а на деле сидит пердун, который и JSON'а-то в глаза не видел и принимает решение: всё делаем на XML!
ЭФ>В принципе непонятно, что мешало сделать любой произвольный 25-ый стандарт DSL для сборки.
Возможно, обилие существующих перделок для XML? Ведь в те времена ты был чуть ли не сенсеем, если умел обрабатывать узлы! И никто даже не задумывался, а удобно ли это — просто совали везде XML как решение "давайте не заморачиваться и захреначим то, что уже умеем".
ЭФ>Как считаете, msbuild заменят новой утилитой сборки (например на основе haskell), или всё, это навсегда?
Навсегда. Потому что "сохранять совместимость со старым г****ном" микрософту легче, чем что-то заново разрабатывать, перенастраивать существующие инструменты, создавать миграционные инструменты... Они даже WPF сделали поверх XML, хотя очевидно, что неуклюжие "теги" никак не приспособлены для UI и "свободного текста" в контролах.
Что они точно неправильно сделали, так это дебильный "новый формат проекта" для Core — теперь ВСЁ, что лежит в каталоге — это сорсы, даже если ты себе сделал "бэкап-файл" какого-нть исходника.
Здравствуйте, Pauel, Вы писали:
K>>>56% java 11 — это повсеместно K>>>9% java 17 — это местами K>>>почти 33% java 8 — это нигде не используется или как назовём? P>·>Т.е. 98% это java 8+. В статье было "java 8 нигде не работает".
P>А также 56 + 33 = 89% это те, что не выше Java 11
P>Как 17 протухнет достаточно, эти 89% промигрируют на нее
По сути эти 89 никто иные как андроиды. 11% это как раз чистая ЯВА
и солнце б утром не вставало, когда бы не было меня
K>>56% java 11 — это повсеместно K>>9% java 17 — это местами K>>почти 33% java 8 — это нигде не используется или как назовём? ·>Т.е. 98% это java 8+. В статье было "java 8 нигде не работает".
Я тебе просто показал, как ява на андроиде отстает от обычной явы. Что тогда, что сейчас.
Проблема поддержки старых версий Андроида была есть и будет.
Но тебе хочется использовать единый код на сервере и разных версиях андроида. И #IFDEF для этого прекрасно подходит
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Baiker, Вы писали:
B>Что они точно неправильно сделали, так это дебильный "новый формат проекта" для Core — теперь ВСЁ, что лежит в каталоге — это сорсы, даже если ты себе сделал "бэкап-файл" какого-нть исходника.
Мне вот ни разу не нужно было хранить бэкапы исходников, зато частые проблемы со старыми файлами две:
1) После добавления новых классов файл проект не сохраняется, в итоге если коммитишь не расширением для Git внутри студии, а через консоль или стороннее приложение, то часто новые модули в коммит попадают, а файл проекта нет. У тебя в итоге локально всё собирается, а на сервере или у коллег будут ошибки отсутствия классов.
2) вечные конфликты в файлах проектов из-за того, что разные сотрудники свои какие-то классы добавляли и теперь это всё вливают в одну ветку.
Здравствуйте, Serginio1, Вы писали:
S>·>Т.е. 98% это java 8+. В статье было "java 8 нигде не работает". S> Я тебе просто показал, как ява на андроиде отстает от обычной явы. Что тогда, что сейчас. S>Проблема поддержки старых версий Андроида была есть и будет. S> Но тебе хочется использовать единый код на сервере и разных версиях андроида. И #IFDEF для этого прекрасно подходит
Не прекрасно. Есть более вменяемые подходы.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Т.е. 98% это java 8+. В статье было "java 8 нигде не работает". S>> Я тебе просто показал, как ява на андроиде отстает от обычной явы. Что тогда, что сейчас. S>>Проблема поддержки старых версий Андроида была есть и будет. S>> Но тебе хочется использовать единый код на сервере и разных версиях андроида. И #IFDEF для этого прекрасно подходит ·>Не прекрасно. Есть более вменяемые подходы.
А можно поподробнее? Заметь, что код на андроид не запустится на винде или линуксе вне эмуляторов.
Если посмотришь исходники библиотек .Net от MS там полно #if.
И тот же #IF DEDUG как на Java. Вещь то нужная и часто используемая.
Твой посыл заключается в том, что байт-код выполняется на любой виртуальной машине.
Но рантайм разный и конструкции байт-код а разный.
Кроме того графика сильно различается.
Конечно есть универсальная графика, но она сильно отстает от платформенной.
Тот же Flutter на Dart е пока по сути на зачаточном уровне. Но и там нужна условная компиляция https://github.com/dart-lang/sdk/issues/35718
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
P>>А также 56 + 33 = 89% это те, что не выше Java 11
P>>Как 17 протухнет достаточно, эти 89% промигрируют на нее
S> По сути эти 89 никто иные как андроиды. 11% это как раз чистая ЯВА
Какие еще андроиды? Найти джависта который сидит хотя бы на 17й то еще приключение
Здравствуйте, Pauel, Вы писали:
P>Какие еще андроиды? Найти джависта который сидит хотя бы на 17й то еще приключение
Ты лучше скажи нужен #IFDEF в яве?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Baiker, Вы писали:
B>>Что они точно неправильно сделали, так это дебильный "новый формат проекта" для Core — теперь ВСЁ, что лежит в каталоге — это сорсы, даже если ты себе сделал "бэкап-файл" какого-нть исходника.
K>Не знаю уж зачем бэкапы в исходниках держать...
Не знаешь — твоё дело, но факт тот, что пока проект развивается, в нём много чего может лежать прямо посреди сорсов. Скажем, ты собираешься делать серьёзный рефакторинг одного файла. Скопировать его в file.LAST_GOOD.cs и можно начать над ним измываться. И есессно, при канпеляции получишь по шапке! Потому что ВНЕЗАПНО какой-то малорослый идиот решил, что "ну его, эти проекты — канпелнём всё махом!". Или ты скопировал чужой пример. Да мало ли вариантов! Пока проект в зародыше, там много чего будет меняться. И канпелять "всё в этом каталоге" — это очень бестолковая идея! Как раз на уровне индусни, которая 3-файловые проекты создаёт.
K> но есть опция: https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#defaultitemexcludes K> <Compile Remove="file.cs.bac" />
Гениально! Теперь я ещё и МУСОР буду добавлять в проект!!! Тебе самому не смешно? Вместо того, чтобы сказать "канпели вот эти три файла", я напишу "вот это мой каталог, только не трогай а, б, в, г... чёрт, г уже нет, зато есть Ъ, который тоже не канпели". Звучит по-идиотски, и сделано по-идиотски.
K>Мне вот ни разу не нужно...
Отучайся от узколобой привычки мерять всё "вот мне не нужно!".
K>1) После добавления новых классов файл проект не сохраняется
Что за чушь? 20 лет студии и ВСЕГДА сохраняется. Если ты делаешь что-то специальное (например, в студии добавил, а сканпелял в ком.строке, не сохранив проект) — ну так это ты ССЗБ! Стыдно винить студию в собственной некомпетентности.
K>2) вечные конфликты в файлах проектов из-за того, что разные сотрудники свои какие-то классы добавляли и теперь это всё вливают в одну ветку.
Опять же, организационный бардак, студия не причём.
