Вышел Apache Maven 3.8.2

А что интересного в 4 будет?

Наконец то вышел тот самый Maven! Кстати что это? Почему в новостях про LibreOffice или Blender люди утруждают себя написать что это за программы, а тут нет? xaizek ты молодец.

Maven — утилита управления жизненным циклом разрабатываемого приложения и его зависимостей. Очень нужная вещь для Java-разработчика.

Ну так может это в новость добавить? Раньше так делали.

Кстати что это?

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

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

А так все пользуются Gradle: https://gradle.org/

Они даже руководство по миграции написали: https://docs.gradle.org/current/userguide/migrating_from_maven.html

Gradle слишком тяжеловесен и сегодня уже малоинтересен. Maven — основная система сборки и тестирования, принятая в IDE Netbeans и Eclipse.

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

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

Устаревшая - это Ant, а Maven вполне нормальная.

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

Потому что Maven всё ешё используется в большом количестве проектов, включая новые проекты.

А так все пользуются Gradle: https://gradle.org/

Не говори за всех. Gradle - это конечно модно, стильно молодёжно и Барух из JFrog писает от него кипятком, но это всё ещё неустоявшаяся система сборки с массой странностей. Только недавно Gradle научили не срать кешем в текущих директориях, даже если там ничего собрать нельзя. У Gradle плохая совместимость вниз, из-за чего с ним приходится тащить враппер - бинарный блоб в котором может оказаться и вредоносный код. И вот при всей своей новизне Gradle, в отличии от Maven, до сих пор не поддерживает Java 17, которая должна выйти через месяц (уже есть RC). А ведь в отличии от поддерживаемой Java 16, Java 17 - это следующий LTS.

14:43:27: Executing task 'build'...

> Task :compileJava FAILED
1 actionable task: 1 executed

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> error: invalid source release: 17

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s
14:43:30: Task execution finished 'build'.

Они даже руководство по миграции написали: https://docs.gradle.org/current/userguide/migrating_from_maven.html

На заборе тоже много чего пишут.

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

Что там вменяемого? Там постоянно что-то меняют, добавляют, объявляют deprecated. Для Java зачем-то сделали сразу два с половиной плагина, из которых нужно выбрать один: java, java-library и application.

Вменяемые люди стараются вообще не использовать Groovy.

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

Ты так говоришь, как будто у Maven’а этого wrapper’а сегодня нет. Вот он, из Gradle слизанный, с таким же бинарным блобом:

https://maven.apache.org/plugins/maven-wrapper-plugin/index.html

Что там вменяемого?

Вменяемо и быстро расширяется под нужды пользователя. Например:

springBoot {
	buildInfo {
		properties {
			additional = [
				'revision': getShortGitRevision()
			]
		}
	}
}

def getShortGitRevision() {
	def commit = 'git rev-parse --short HEAD'
	def count = 'git rev-list --count HEAD'
	try {
		return [commit.execute().text.trim(), count.execute().text.trim()].join('_')
	} catch (IOException ignored) {
		return 'unknown'
	}
}

Чтобы под Maven сделать подобную штуку нужно намного больше телодвижений.

Вменяемые люди стараются вообще не использовать Groovy.

К твоим услугам всегда Kotlin DSL, если не нравится Groovy DSL.

Я так говорю потому, что по умолчанию в Maven его нет и нет особой необходимости его вообще использовать. То, на что ты дал ссылку, сегодня таки вообще нет, потому что этот плагин работает лишь с Maven 4, который ешё не вышел. Да, какой нибудь start.spring.io пихает mvnw и mvnw.cmd, но не пихает никакой нинарный блоб прямо в проект, как это делает неразумный Gradle. Вместо этого он скачивает https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.5.6/maven-wrapper-0.5.6.jar что гораздо чище и безопаснее. Бинарные блобы в VCS - это зло, за которое нужно бить ногами.

Да, какой нибудь start.spring.io пихает mvnw и mvnw.cmd, но не пихает никакой нинарный блоб прямо в проект, как это делает неразумный Gradle.

Кажется, кто-то забыл про скрытые директории:

https://github.com/spring-guides/gs-securing-web/tree/main/complete/.mvn/wrapper

Ничего не устаревшая. Например есть очень популярный и многообещающий фреймворк Quarkus. У него основной системой сборки является именно Maven.

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

А если хочется чего-то навороченного, то лучше уж брать Bazel, а не Gradle.

Кстати почитал немного про Maven 4. Есть шансы, что они исправят наркоманскую работу с многомодульными проектами. Если это будет так, я хорошо подумаю над тем, чтобы окончательно вернуться на Maven.

Скрипт скачивает бинарники, если их там нет.

Мальчик, в суровом тырпрайсе многие ещё мечтают о мавен.

А пользуются встроенной в Eclipse системой сборки jar-ов.

А на CI сервере до сих пор используют ant.

Я ещё раз повторю - скрипт скачивает этот бинарник, если его там нет. Открой скрипт и почитай его.

Зачем спринг решил засунуть этот бинарник в какой-то зип, надо спрашивать у него.

Чтобы под Maven сделать подобную штуку нужно намного больше телодвижений.

Нужно всего лишь добавить один плагин, официально поддерживаемый проектом Spring Boot.

            <plugin>
                <groupId>io.github.git-commit-id</groupId>
                <artifactId>git-commit-id-maven-plugin</artifactId>
                <version>5.0.0</version>
                <executions>
                    <execution>
                        <id>get-the-git-infos</id>
                        <goals>
                            <goal>revision</goal>
                        </goals>
                        <phase>initialize</phase>
                    </execution>
                </executions>
                <configuration>
                    <generateGitPropertiesFile>true</generateGitPropertiesFile>
                </configuration>
            </plugin>

Затем нужно использовать его в коде и конкатенировать там же, а не заниматься ерундой с кастомными пропертями в BuildInfo

package com.example.demo.controllers;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.info.GitProperties;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DemoController {

    private final GitProperties gitProperties;

    @Autowired
    public DemoController(GitProperties gitProperties) {
        this.gitProperties = gitProperties;
    }

    @GetMapping("/revision")
    public String revision() {
        return gitProperties.getShortCommitId() + '_' + gitProperties.get("total.commit.count");
    }
}

Кажется, кто-то забыл про скрытые директории:

Ну хорошо, тоже тащит. Но всё таки по умолчанию mvnw не создаётся, в отличии от gradlew.

У вас шесть опечаток в слове sbt.

Помню как Барух долго разорялся на презентации про транзитивные зависимости и как это сделано в Maven, якобы хуже, чем в Gradle.

Из официальной документации https://github.com/takari/maven-wrapper/blob/master/README.md

Usage without Binary JAR

By default, the Maven Wrapper JAR archive is added to the using project as small binary file .mvn/wrapper/maven-wrapper.jar. It is used to bootstrap the download and invocation of Maven from the wrapper shell scripts.

If your project is not allowed to contain binary files like this, you can configure your version control system to exclude checkin/commit of the wrapper jar.

If the JAR is not found to be available by the scripts they will attempt to download the file from the URL specified in .mvn/wrapper/maven-wrapper.properties under wrapperUrl and put it in place. The download is attempted via curl, wget and, as last resort, by compiling the ./mvn/wrapper/MavenWrapperDownloader.java file and executing the resulting class.

If your Maven repository is password protected you can specify your username via the environment variable MVNW_USERNAME and the password via the environment variable MVNW_PASSWORD.

Я как пользователь с проблемами в данном аспекте не сталкивался. Допускаю, что они есть в каких-то нюансах, но никаких отличий от Gradle я не заметил.

У вас три опечатки в слове ant

Он говорил о разрешении коллизий в транзитивных зависимостях. Вот например такое дерево зависимостей:

     [A 2.1.2]
       /    \
      /      \
     /        \
 [B 5.0.7]  [C 2.1.7]
     |        |
     |        |
     |        |
  [D 4.1]  [E 3.2.5]
     |
     |
     |
 [E 4.0.2]

Понятно что две версии одной и той же зависимосте E в одном classpath ужиться не могут и даже Java 9+ modules не помогут, потому что поддержку нескольких версий модулей от туда выпилили ещё на стадии разработки. Как же быть? Должен остаться кто-то один - лишь одна версия зависимости E. Но какая? В Maven останется та версия, которая ближе к корню дерева зависимостей, в нашем случае E 3.2.5, что скорее всего сделает неработоспособной зависимость D. Это можно переопределить, прописав D или нужную ему версю E нетранзитивно, то есть приблизив E 4.0.2 к корню. В случае Gradle останется самая новая версия, в нашем случае E 4.0.2. Gradle делает ставку на обратную совместимость зависимостей, что работает не всегда, но якобы в большенстве случаев работает и поэтому нравится Баруху. Ещё он долго разорялся по поводу того, что изменить реализацию разрешения таких коллизий в Maven нельзя, а в Gradle можно на любую другую, что впрочем мало кем используется.

Уж если кто на 200% устаревший, так это именно ant.

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

Почему ant устаревший? ant отличный инструмент. Просто подход не слишком хорош, при наличии других подходов, но если нужен именно такой подход, альтернатива ant-у - только писать shell-скрипт, что будет заведомо хуже.

Это ты будешь на демонстрации maven говорить. Но бюджет на перевод 50 проектов вы все равно не получите.

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

Ну вот Gradle - как раз одна из альтернатив Ant-а. В Ant мы говорим как хотим собирать проект, в Maven - что мы хотим собирать, а в Gradle оба эти варианта одновременно. Проблема Gradle в том, что он слишком перегружен, до сих пор не устоялся, плохо поддерживает совместимость. Например в Maven нужен лишь pom.xml а в Gradle зачем-то решили, что одного файла им мало. До 7-й версии Gradle «срал» директорией .gradle везде, где его пытались запустить. Ну и так далее. В Maven гибкость сборки (возможность сказать как мы хотим собирать) обеспечивается плагинами. Большинство претензий к Maven сводятся к неудобству использования этого механизма когда требуется написать собственный плагин.

Нет уж, спасибо, есть дела поважнее, чем переводить проекты с ant на maven и обратно.

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

Тогда 80 процентов ынтырпрайса останется сидеть на ant. А остальные 20 на Maven. И только меньше процента будут юзать хипстеровский Gradle.

Это новые проекты в тырпрайсе на мавен начинаются. А вот в легаси монолит намертво прибит ant.

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

Это не новость что энтерпрайз не умеет программировать по большей части, и не знает как оптимально организовать рабочий процесс. Спасибо за ещё одно подтверждение.

А как хипстеровский Gradle, который только для мобилок, помогает организовать рабочий процесс тырпрайса и научить программировать тырпрайс программистов?

И каким образом Maven ухудшает или блокирует рабочий процесс?

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

Затем видел стартап, в котором выбрали Maven, а не хипстерский Gradle, хотя для стартапов хипстерство как раз таки более ожидаемо, чем для больших энтерпрайзов. Просто там система сборки выбиралась не группой девопсов (переживающих за свой job security), а самими разработчиками, которым нужно просто чтобы работало и не отвлекало.

Просто там система сборки выбиралась не группой девопсов (переживающих за свой job security)

Вы так говорите, как будто по результатам анализа Gradle и Maven DevSecOpsерами таки победил Gradle

Ну в основном за Gradle топят именно девопсы. Тот же Барух Садогурский - технический адвокат компании JFrog, которая специализируется на сервисах для девопсов.

А, ха ха :)

очень популярный и многообещающий фреймворк Quarkus

Можете объяснить, что это за поделие? Я зашел почитать на официальный сайт и там один маркетинговый булшит. А по примерам очередное поделие от индусов для хипстерков.

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

Совсем уже хипстерок?

А так все пользуются Gradle: https://gradle.org/

«Все»? За базар ответишь?

Не, это практически официальный фреймворк чуть ли не от оракла. То, как они видят будущее джавы.

Там основная фишка в том, что они компилят результат в бинарник. Который потом предполагается запускать в контейнере, ну в общем микросервисы в кубернетесе, всё, как сейчас модно.

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

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

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

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

В целом можно сказать, что они взяли спринг бут и переделали его с нуля по-человечески.

Единственное, что мне прям сильно не понравилось - это магия. Например они предлагают делать поле публичным и писать снизу геттер-сеттер. В жава коде ты просто используешь это публичное поле. Но при этом какой-то там препроцессор байткода меняет эти обращения к полю на вызовы геттеров-сеттеров. В общем эдакая имитация properties. Я такое ненавижу. Но в принципе никто не заставляет таким пользоваться. А в остальном проект очень достойный внимания, если твой юз-кейс совпадает с ихним (микросервис для запуска в кубернетесе).

В целом для расширения кругозора познакомиться стоит в любом случае, имхо. Это самый многообещающий фреймворк после спринга.

автоперезапуск при изменениях и прочие современные штуки

современные штуки

Мдя. Расскажи этим индусам, что в JVM можно не рестаровать процесс, а обновлять код на горячую с сохранением стейта, как это сделано в tapestry еще лет 5 назад.

по умолчанию всё уже настроено адекватно

делать поле публичным и писать снизу геттер-сеттер

Мдя… В общем, я не ошибся с первым впечатлением. Всё для хипстерков от индусни. Кушайте, не обляпайтесь.

Но при этом какой-то там препроцессор байткода меняет эти обращения к полю на вызовы геттеров-сеттеров.

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

Это передача в инфиксную функцию сохдаваемого экземпляра класса. И из кода, то что ты в хип насрал, да еще и инфикс дернул нифига не следует :)

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