Вышел Apache Maven 3.8.2

Это они котлиновского говна насмотрелись. Когда вообще непонятно, что твой код делает типа s should startWith(«A»)

В котлине как раз всё понятно, если ты его знаешь и IDE под боком. Пощёлкай на should, посмотри типы и всё станет понятно, что куда вызывается. Тут никакой магии нет. Даже если я эту библиотеку не знаю, но сам язык знаю, я легко в этом разберусь.

А вот в описываемом мною случае в коде написано одно, а выполняется другое. Библиотека меняет байткод совершенно неочевидным образом. И для понимания кода нужно не только знать сам язык, но и знать эти «приколы» библиотеки-фреймворка.

Хотя в жаве, к сожалению, такое не редкость. Будь у меня куча времени и денег, написал бы сам нормальные библиотеки. А то все поголовно - плохие. По крайней мере с моей точки зрения.

Я код смотрю в gitlabe, когда ревью делаю. Язык, прибитый гвоздями в среде разработки - гавно. ИМХО конечно, пользуйтесь чем угодно.

А зачем на бекенде скомпилированный код? На бекенде JIT, после разогрева, должен уделывать статичный бинарь.

Есть же божественный CMake, какие проекты на Java его используют кстати?

На бекенде JIT, после разогрева, должен уделывать статичный бинарь.

За сколько выполняется разогретый бесконечный цикл?

Когда у тебя миллион контейнеров с jvm в каждом, это бабки. По производительности кого кто уделает, затрудняюсь ответить, конкретно смотреть нужно.

Если у тебя бабки, запили нормальный ЯП и ОС, а не костыли к JVM. Хотя, когда мозгов нет, только на костыли и остается.

поделие от индусов для хипстерков

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

Ни один вменяемый индус не пойдет сейчас работать за нищенскую зарплату в разработку, особенно, если он сумел свалить в Германии.

Любой индус вам скажет, что в QA TA TE SDT гораздо больше бабла, чем в продуктовой разработке.

Зы. Роль индусов уже цать лет назад пробег переняли сирийцы, пакистанцы и китайцы.

Зачем мне выкидывать представления? Я прекрасно наблюдаю как они уделали Eclipse. Когда граница моего чудовищного терпения была преодолена, я на всякий случай зашел в issue, посмотреть так сказать есть ли надежда на спасение. Но нет, я увидел их лица и имена и в порыве отчаяния перешел на IDEA.

За сколько выполняется разогретый бесконечный цикл?

Задай этот вопрос своему учителю информатики.

Поздравляю тебя с переходом с одного нинужно на другое.

Ты естественно спросил разрешение у CIO, да?

И да, ты прикинь, в IntelliJ коммунити уже есть мем про последнюю нормальную версию IDEA.

Угадай с одного раза какого года.

Так а ты на чём пишешь, вундеркинд? На бумажке или перфокарте программы набиваешь?

Ну вот опять эти ваши перегибы и гиперболы.

Тырпрайсная джаба выстрелила в банках в середине нулевых. Туда пришли выпускники немецких FH, которые в 2001м сдавали первую курсовую на джава, когда единственным средством сборки был Ant. Ни Maven, ни, тем более Gradle тогда ещё в помине не было.

Далее они заматерелили и ушли куда то ещё. А банку нужны новые прогеры. Которых дешевле учить под конкретный стек, который у них используется. На это есть аусбильдунг.

В итоге никто за цать лет так и не отважится поменять этот ваш старый, но отнюдь не устаревший Ant на более хипстеровский Maven и Gradle.

А кто-нибудь в maven нормальную ci смог сделать, так чтобы если каждая команда пилит свой компонент, и так сделать, чтобы собрался продукт и протестировался, но при этом компонент взялся из бранча.

То есть snapshot не прокатывает, так как он один, а бранчей много.

То есть snapshot не прокатывает, так как он один, а бранчей много.

Конвенция о версиях зависимостей — какую версию (серию версий) укажешь, такой (последний в серии) компонент и возьмётся из репозитория.

Это как? Вот сидит один девелопер, делает feature/1. Второй - feature/2. Оба сделали по pull request. Как проверить, что каждая фича по отдельности не ломает продукт?

И если дальше усложнять, как гарнировать, какой конкретный коммит тестируется? Например, пока один коммит ещё не закончил проверяться (ну длинный тест, скажем), уже второй собрался (например, опечатку поправил).

А зачем проверять их по отдельности? В итоге то работать они будут вмести, вот вмести и проверить.

Ну вот опять эти ваши перегибы и гиперболы.

Так ты не ответил на вопрос.

Ant

Оно ещё хуже Gradle, программировать на xml-е это удел индусов. Белые люди пишут плагины для Maven.

Gradle

Это поделие умерло не родившись, как и недоязычок, на котором оно написано.

Слышал на ондроиде его используют, так на этом ондроиде одна содомия - фрагментировали джаву, так ещё и отказались от ее поддержки. Вот и содомят хипстеры друг друга в попы, то на котлине, то на градле, в перерывах попивая смузи. И думают, что на современной джаве занимаются тем же.

Я говорю не про репозиторий VCS, а про репозиторий Maven и конвенцию о версиях jar в POM-файлах.

Зачем ты мне тогда отвечаешь не на мой вопрос?

Вот сидит один девелопер, делает feature/1. Второй - feature/2. Оба сделали по pull request. Как проверить, что каждая фича по отдельности не ломает продукт?

JAR’ники с собственными фичами публикуются самими разработчиками в тестовом Maven-репозитории естественно под собственными версиями.

В POM-файле зависимого от одного из них проекта указывается НУЖНАЯ версия JAR-файла. Проект собирается и тестируется с JAR-файлом, в котором реализована нужная фича. Всё.

У нас дженкинс с бранчей собирает спокойно, каким тут боком мавен нужен, непонятно. Проектов на куче всего много, завязывать сложную сборку на мавен нет смысла. Девопсы вынесли все в дженкинс и запилили сборки в том числе мавен проектов в единой среде. От мавена надо только что бы по mvn clean deploy собралось и положилось куда надо то, что надо.

JAR’ники с собственными фичами публикуются самими разработчиками

Мдя… Отличный CI.

Так если хочется Грааль, есть ещё micronaut от Грэма Роше. И, соответственно, DI там compile time. Насколько помню, вышел он раньше Quarkus. Спринговый стиль.

И да, вся сборка самого фрейма на gradle.

Устаревшая система сборки для Java.

Java сама по себе устаревшая система программирования.

Пишут потому что лень что то учить, да и диды на Java писали, вот и мы…

До сих по Ant встречается.

Поэтому gradle врядл когда нибудь станет популярным.

Разве что среди «бунтарей», которым кроме Java что-то учить лень, но выежнуться хочется.

Gradle для Kotlin используется.

Ага.

Ведь Котлин такая-же маргинальщина для «бунтарей» на Java

ПС
Чего только «бунтари» не придумают только бы как деды.

Gradle с двумя вменяемыми DSL лучше этой XML-дрисни.

Конечно, DSL-каша ака «я художник – я так вижу» гораздо лучше чётко структурированной «XML-дрисни».

Всё жду, когда же переведут синтаксис Maven с XML на JSON.

С помощью XSLT и такой-то матери это доступно уже сейчас. Вопрос только зачем?

Избавиться от «мусорных» скобочек. Они захламляют восприятие — когда в лесу отдельных сосен не видно.

С помощью XSLT и такой-то матери это доступно уже сейчас. Вопрос только зачем?

С каких пор XSLT научился трансформировать не-XML в XML? Он умеет лишь наоборот или из одного XML в другой.

Всё жду, когда же переведут синтаксис Maven с XML на JSON.

https://www.baeldung.com/maven-polyglot

Так я и написал «и такой-то матери», подразумевалось, что обратную транформацию придётся колхозить.