LINUX.ORG.RU

Вышел Apache Maven 3.8.2

 , ,


0

2

Maven – утилита управления жизненным циклом приложений на платформе Java, а также их зависимостями.

После четырёх месяцев с момента предыдущего релиза и ещё недели тестирования окончательной сборки объявлено о выходе нового минорного обновления Apache Maven 3.8.2. Эта версия включает исправление 30 ошибок, 22 улучшения и несколько обновлений версий плагинов, используемых по умолчанию, включая обновления, закрывающие некоторые проблемы с безопасностью. Полный список изменений, со ссылками на соответствующие тикеты Jira, можно найти здесь.

В ближайшее время ожидается выход новой мажорной версии Apache Maven 4.0.0.

>>> Анонс



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

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

Legioner ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Устаревшая система сборки для 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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Я так говорю потому, что по умолчанию в 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 - это зло, за которое нужно бить ногами.

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

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

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

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

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

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

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner
$ curl https://start.spring.io/starter.zip -d dependencies=web,devtools -d bootVersion=2.5.3.RELEASE -o my-project.zip
$ unzip my-project.zip | grep jar
  inflating: .mvn/wrapper/maven-wrapper.jar
EXL ★★★★★
()
Ответ на: комментарий от fsb4000

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

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

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner
C:\Users\Vladimir\Projects\Test>curl https://start.spring.io/starter.zip -d dependencies=web,devtools -d bootVersion=2.5.3.RELEASE -o my-project.zip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 56594  100 56543  100    51  56543     51  0:00:01 --:--:--  0:00:01 69697

C:\Users\Vladimir\Projects\Test>"\Program Files\WinRAR\WinRAR.exe" x my-project.zip my-project/

C:\Users\Vladimir\Projects\Test>cd my-project

C:\Users\Vladimir\Projects\Test\my-project>del .mvn\wrapper\maven-wrapper.jar

C:\Users\Vladimir\Projects\Test\my-project>set JAVA_HOME=C:\Users\Vladimir\Applications\zulu8.52.0.23-ca-fx-jdk8.0.282-win_x64

C:\Users\Vladimir\Projects\Test\my-project>.\mvnw.cmd clean
...
C:\Users\Vladimir\Projects\Test\my-project>dir .mvn\wrapper
 Volume in drive C has no label.
 Volume Serial Number is 981A-D20F

 Directory of C:\Users\Vladimir\Projects\Test\my-project\.mvn\wrapper

08/14/2021  18:55    <DIR>          .
08/14/2021  18:55    <DIR>          ..
08/14/2021  18:55            50,710 maven-wrapper.jar
08/14/2021  12:53               218 maven-wrapper.properties
08/14/2021  12:53             4,942 MavenWrapperDownloader.java
               3 File(s)         55,870 bytes
               2 Dir(s)  1,581,446,672,384 bytes free
Legioner ★★★★★
()
Ответ на: комментарий от EXL

Чтобы под 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");
    }
}
hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от EXL

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

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

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

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

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

Из официальной документации 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.

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

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

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

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

     [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 можно на любую другую, что впрочем мало кем используется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от fsb4000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 2)
Ответ на: комментарий от Legioner

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

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

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

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

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

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