LINUX.ORG.RU

Gradle 7.2

 , , , ,


0

1

Не прошло и полутора месяцев с предыдущего релиза 7.1.1, как на свет появилась новая версия Gradle 7.2 — системы сборки, наиболее популярная среди разработчиков на Java и на других языков программирования JVM, включая разработчиков под Android.

Среди интересных изменений следующие:

  • Gradle может компилировать под Java 17 (сейчас есть RC, релиз в сентябре).
  • Java toolchain теперь поддерживает ещё и Scala.
  • Добавлена новая аннотация @NormalizeLineEndings позволяющая нормализовать формат конца строки. За счёт использования этой аннотации уже улучшена производительность задачи JavaCompile.
  • Улучшена поддержка аутентификации доступа к репозиториям по HTTP. Автоматически поддерживаются параметры <rep_name>AuthHeaderName и <rep_name>AuthHeaderValue (где <rep_name> - название репозитория), значения которых используются во время аутентификации через HTTP-заголовки.
  • В дополнении к Copy.expand(Map) был добавлен метод Copy.expand(Map,Action), позволяющий копировать файлы без преобразования escape-последовательностей. Для этого нужно установить escapeBackslash = true.
  • Попытки повторить HTTP-запросы во время удалённой сборки теперь происходят не только для HTTP GET, но и для HTTP PUT.
  • HTTP-редиректы во время удалённой сборки теперь поддерживаются по умолчанию.

Также исправлено 50 ошибок.

>>> Подробности



Проверено: cetjs2 ()
Последнее исправление: unfo (всего исправлений: 9)

Ответ на: комментарий от vikrom

Он не для людей.

Весьма спорный аргумент.

Помимо того, что XML вполне человекочитаемый, у него есть масса других преимуществ:

  • Полная поддержка в стандартной библиотеке Java (SAX, StAX, DOM)
  • Валидация по схеме: XSD или DTD
  • XPath
  • XSLT

Для JSON такое если и есть, то с гораздо худшими возможностями.

hummer
() автор топика
Ответ на: комментарий от hummer

Не, там был случай rockstar-разработчика, который умел писать быстро и много java-кода. А остановиться и осознать, что иногда лучше совсем ничего не писать, не умел. Ну и он написал так на gradle этом от души, каких-то финтифлюшек надобавлял для своего удобства как ему хотелось… а потом ушёл куда-то совсем в другое место.

А его оставшиеся коллеги потом этот gradle-овый конфиг старались не открывать и передавали друг другу как исторический артефакт. Типа вот с этой стороны подходишь посолонь, три раза плюнешь через плечо, нажмешь enter и что-то должно собраться…

alpha ★★★★★
()
Ответ на: комментарий от vikrom

Ты толпоеп или прикидываешься?

В суровом тырпрайсе XML для валидации читается не людьми, а Groovy скриптами.

В отделе автоматизации тестирования.

GP
()
Ответ на: комментарий от vikrom

Ну а конкретнее, что в XML не нравится? А то асоциация с вилкой какая-то совсем некорректная.

hummer
() автор топика
Ответ на: комментарий от GP

Ну pom.xml пишут как раз таки люди. Единственное, что там действительно может не нравиться, так это необходимость прописать схемы в самом начале.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

Обычно никто не может написать это вручную. Впрочем IntelliJ умеет создавать заготовки pom.xml и самому возиться со схемами не приходится.

hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от GP

Это не трудности, это попытка понять тех, кто жалуется.

hummer
() автор топика
Ответ на: комментарий от hummer

Конкретно и сказал - он не для человеческих глаз. Ну т.е. человек ко всему привыкает, это понятно. Но когда есть инструменты удобнее - зачем привыкать? Когда XML нужен, чтобы гонять валидированные данные, а не смотреть в него глазами - тогда с ним все Ок.

vikrom
()
Ответ на: комментарий от hummer

Жаль, что maven этими преимуществами толком не пользуется. Той же нормальный схемы для pom.xml нет. namespace-ы как положено не используются (например плагины должны добавлять свои схемы и конфигурация плагинов должна использовать кастомную схему).

Legioner ★★★★★
()
Ответ на: комментарий от vikrom

Не для человеческих глаз JSON, YAML и прочие ублюдства. А XML как раз таки хорошо читаем за счёт закрывающихся тегов.

Legioner ★★★★★
()
Ответ на: комментарий от vikrom

По твоей же логике HTML не для человеческих глаз

GP
()
Ответ на: комментарий от Legioner

Схема для pom.xml как раз есть и в какой-то момент её решили больше не менять. Вроде бы именно с этим связана невозможность определять альтернативные реализации разрешения коллизий в транзитивных зависимостях. Для кастомных схем плагинов они должны использовать альтернативные пространства имён, что сделает pom.xml ещё более награмождённым.

hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от hummer

Схема для pom.xml как раз есть и в какой-то момент её решили больше не менять.

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

Для кастомных схем плагинов они должны использовать альтернативные пространства имён, что сделает pom.xml ещё более награмождённым.

Ничего нагромождённого там нет. Те, для кого одна строчка это нагромождение, должны уйти из профессии. Каждый Java-файл начинается с package xxx; - ничего, живём как-то с таким «нагромождением». Про импорты вообще молчу.

Legioner ★★★★★
()
Ответ на: комментарий от cdshines

Кликнул там на другие графики – лажа какая-то. Линукс с 0.9% опережает Винду (!) с 0.6%, и других ОСей на графике нет. Андроид 4%, айОС с 1.5%, и других мобильных ОСей на графике тоже нет.

the1 ★★
()
Ответ на: комментарий от Legioner

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

Каких разделов? Разве что конфигурации плагинов произвольные, а всё остальное жёстко прописано в maven-4.0.0.xsd. В чём практический смысл дополнительных схем? Это разве что для автодополнения удобно.

hummer
() автор топика
Ответ на: комментарий от the1

и других ОСей на графике нет

Слева от графика ты можешь добавить всё что угодно. При этом URL в браузере тоже обновится. Вот например график по языкам программирования:

https://insights.stackoverflow.com/trends?tags=java%2Ckotlin%2Cscala%2Cpython%2Cc%23%2Cc%2B%2B%2Crust%2Cperl%2Cgroovy

hummer
() автор топика
Ответ на: комментарий от hummer

Да, конфигурация плагинов, что является самым геморным.

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

Это удобно и для автодополнения и для валидации (чтобы валидировать статически, а не пытаясь запускать).

Legioner ★★★★★
()
Ответ на: комментарий от the1

Ты же в курсе, что это сайт для вопросов-ответов о программировании? Поэтому судить о популярности средства сборки по нему - разумно, а делать выводы и популярности ОС - нет.

cdshines ★★★★★
()
Ответ на: комментарий от cdshines

это сайт для вопросов-ответов о программировании? Поэтому…

Мне кажется что моя опровергающая аргументация типа «если в чём-то врёт, то ни в чём нельзя верить» сильнее чем твоя поддерживающая.

Ну да ладно, я не настаиваю и не спорю. Помню, ты специалист. Как минимум в вэбе.

@hummer

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

the1 ★★
()
Ответ на: комментарий от the1

если в чём-то врёт, то ни в чём нельзя верить

Это не лишено смысла в каких-то случаях, но здесь суть в том, что он не врет (и a->b, и при этом !а не означает, что !b). Это как если бы программисты интересовались в основном электромобилями, а мы сделали вывод, что на форуме программистов-автолюбителей врут о средней статистике по авторынку.

cdshines ★★★★★
()
Ответ на: комментарий от vikrom

XML конечно не сахар, но в 100% случаев нужно указать нужные зависимости в декларативном стиле и решить свои проблемы с помощью гугла без мозгонапрягательства. Все остальное - это для тех, кто любит страдать. И если сравнивать maven и gradle, то maven выигрывает по всем параметрам. Жду, когда в Java появится нормальная система сборки, где ты просто пишешь команду и все само добавляется и исправляется в конфиге, как, например, в npm, хотя и эти успели обделаться со своим package-lock ом. Вообщем, несмотря на отвращение к мавену, все остальное ещё хуже. Тоже самое с Java.

summon
()
Ответ на: комментарий от summon

Вообщем, несмотря на отвращение к мавену, все остальное ещё хуже. Тоже самое с Java.

Не хуже, но «задёргивается шторкой».

К примеру, Object Pascal. Модульность из концепции раздельной компиляции программных сущностей в массовом использовании появилась именно с выходом Turbo Pascal 4.0 (ешё в 1987 году).

iZEN ★★★★★
()
Ответ на: комментарий от alpha

а поменять свой проект так, чтобы он хорошо попадал в дефолты gradle

Практически нереально если используется несколько систем сборки под разные платформы.

В целом впечатление от использования грейдла на больших проектах - назначается кто-то, кому придётся вникнать в парадигму грейдл-вей и погружаться в документацию чтобы потом разбираться с проблемами за всех. Заставить всех разработчиков разбираться невозможно, «настроить и забыть» тоже не про грейдл.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.