Знаю, он не идеальный, но по крайней мере я попытаюсь рассказать, как его к этому приблизить.
В одну заметку всё не войдёт, поэтому сначала план:
- Постановка задачи — описание той конфигурации проектов с которой мы будем работать, целей и проблем
- Как настроить мавен для разработки в рамках нашей задачи
- Как настроить CI/CD (билды, релизы, деплоймент)
- Нерешенные проблемы
Задача
Итак, начнем с постановки задачи. Предположим у нас есть группа людей (компания, фирма, кружок), которые разрабатывают проекты на Java. При этом у них есть как проекты с открытым кодом (OSS), так и проекты с закрытым кодом. Проекты, назовём их внутренние, разрабатываются независимо друг от друга, но между ними есть зависимости. Что хочется:
- Централизованное управление зависимостями на внешние библиотеки
- OSS проекты в центральном мавен репозитории
- Закрытые проекты в своём мавен репозитории.
- «Простой» релиз внутренних проектов с обновлением зависимости в зависимых проектах.
- Максимальная автоматизация всех хотелок.
Важно понимать, что решать эти проблемы мы будем в комплексе, поэтому без реализации всех хотелок, система работать вообще не будет или будет, но не в полную силу.
Так же я хочу сказать, что все ниже написанное, это моё личное мнение, я осознаю, что мавен можно настроить по-разному, и я со своей стороны очень надеюсь найти нечто новое в обсуждении этой статьи, что поможет сделать существующую модель еще лучше. В свою защиту могу сказать, что модель, которую я буду описывать уже работает, и не один год. Открытая часть лежит на BitBucket, в частности, здесь.
Настраиваем мавен
Централизованное управление зависимостями на внешние библиотеки
Для управления сторонними зависимостями у мавена есть специальная секция dependencyManagement и механизм наследования. Казалась бы – вот и ответ, делаем «корпоративный» POM и наследуем от него корневые POM’ы всех наших проектов. Да, так и будет, но вот детали…. Итак, вот он наш будущий «корпоративный» POM:
<?xml version="1.0" encoding="UTF-8"?>
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.team</groupId>
<artifactId>org.team.pom</artifactId>
<version>0-SNAPSHOT</version>
<packaging>pom</packaging>
<properties>
<spring.version>4.3.12.RELEASE</spring.version>
<junit.ver>4.12</junit.ver>
</properties>
<dependencyManagement>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>${spring.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- Exclude commons-logging from whole Spring -->
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.ver}</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
`<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.2</version>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20.1</version>
</plugin>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.0</version>
</plugin>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.0.0</version>
</plugin>
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
</plugin>
<plugin>
<artifactId>maven-site-plugin</artifactId>
<version>3.5.1</version>
</plugin>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
</plugin>
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.2</version>
</plugin>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<version>3.1.0</version>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>Всё стандартно, но хочу обратить внимание не некоторые вещи:
- Будуте копировать, уберите апостроф на в конфигурации
maven-compiler-plugin. Он там для того, что бы местный редактор не заменял<source>на три апострофа. - Это не финальная версия, а минимальная, которую мы будем дописывать в следующих частях.
- Версии всех компонент вынесены в секцию переменных. Для 2-3 зависимостей не важно, но, когда у вас их 50 и секция dependencyManagement занимает несколько экранов это здорово облегчает обновление версий.
- Кроме собственно версий в секции dependencyManagement можно переопределить область применения (sсope) зависимости и убрать некоторые транзитивные зависимости. Данной возможностью лучше не злоупотреблять и всегда писать комментарии зачем и почему это так сделано.
- Так же в нашем POM’е присутствует секция pluginManagement. Ее роль примерно такая-же – централизованное управление плагинами, используемыми для построения проекта. Почему это важно? По умолчанию мавен использует последние доступные версии плагинов. Так что, билд с одних и тех же исходников сейчас и через год может отличатся или просто не пройти. С помощью этой секции мы фиксируем версии плагинов, что по идеи минимизирует возможные расхождения.
- Еще одна возможность – это определить общие конфигурационные параметры для плагинов – например, версию байткода, которую мы используем во всех наших проектах.
- И не очень существенный пункт, пока мы не дошли до релизов, это версия нашего POM’а. Я написал её как
0-SNAPSHOT. На самом деле важно, чтобы это был любой SNAPSHOT. Мы её менять в будущем не будем. Почему, расскажу в следующих статьях.
С какими проблемами/непонятками обычно сталкиваются при использовании «корпоративного» POM’а?
- Непонятно, как делать релизы (не надо)
- Надо ли включать отдельные проекты как модули (не надо)
- Надо ли в «корпоративном» POM’е описывать версии внутренних проектов (не надо)
- Как отслеживать и как часто обновлять версии внешних библиотек
- Непонимание различия между «корпоративного» и корневым POM отдельного проекта
Все это мы разберём в следующих частях это статьи. Сейчас кратко остановлюсь на двух последних пунктах.
Различие между «корпоративным» POM’ом и корневым POM отдельного проекта
«Корпоративный» POM описывает общие правила для всех ваших проектов в компании – как-то версия Java, зависимости и их версии, общие ограничения на проекты, за которыми может следить мавен, контакты на разработчиков и т.д. В «корпоративном» POM’е не должно быть информации («зависимостей») о конкретных внутренних проектах — их версий, специфичных профайлов и подобных вещей.
Как отслеживать и как часто обновлять версии внешних библиотек
Версии библиотек/плагинов можно легко отслеживать с помощью самого мавена (плагин versions-maven-plugin). Для этого добавим в наш «корпоративный» POM в секцию pluginManagement следующий фрагмент
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>versions-maven-plugin</artifactId>
<version>2.5</version>
<configuration>
<rulesUri>file://${user.dir}/rules.xml</rulesUri>
<generateBackupPoms>false</generateBackupPoms>
</configuration>
</plugin>А рядом с pom.xml создадим файл rules.xml со следующим содержимым
<ruleset comparisonMethod="maven" xmlns="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd">
<ignoreVersions>
<ignoreVersion type="regex">.*-does-not-exist</ignoreVersion>
<ignoreVersion type="regex">.*[Aa]lpha.*</ignoreVersion>
<ignoreVersion type="regex">.*(?i)beta.*</ignoreVersion>
<ignoreVersion type="regex">.*pre.*</ignoreVersion>
<ignoreVersion type="regex">.*[Dd]raft.*</ignoreVersion>
<ignoreVersion type="regex">.*-rc.*</ignoreVersion>
<ignoreVersion type="regex">20041228\.180559</ignoreVersion>
<ignoreVersion type="regex">.*jbossorg.*</ignoreVersion>
<ignoreVersion type="regex">.*dev.*</ignoreVersion>
<ignoreVersion type="regex">\d+\.\d+</ignoreVersion>
<ignoreVersion type="regex">.*(19|20)\d\d(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01]).*</ignoreVersion>
<ignoreVersion type="regex">.*jboss.*</ignoreVersion>
<ignoreVersion type="regex">.*atlassian.*</ignoreVersion>
<ignoreVersion type="regex">.*xwiki.*</ignoreVersion>
<ignoreVersion type="regex">.*b\d\d</ignoreVersion>
<ignoreVersion type="regex">.*_ALPHA</ignoreVersion>
<ignoreVersion type="regex">.*M\d</ignoreVersion>
<ignoreVersion type="regex">.*RC\d</ignoreVersion>
<ignoreVersion type="regex">.*\.jre7</ignoreVersion>
<ignoreVersion type="regex">.*\.jre6</ignoreVersion>
<ignoreVersion type="regex">.*CR\d</ignoreVersion>
<ignoreVersion type="regex">.*M\d*</ignoreVersion>
<ignoreVersion type="regex">.*pr\d</ignoreVersion>
<ignoreVersion type="regex">.*android</ignoreVersion>
<ignoreVersion type="regex">.*m\d*</ignoreVersion>
<ignoreVersion type="regex">.*p\d*</ignoreVersion>
</ignoreVersions>
</ruleset>В принципе это делать не обязательно, и строчку <rulesUri>file://${user.dir}/rules.xml</rulesUri> можно убрать. У меня это файл служит для фильтрации различных «мусорных» версии которые я предпочитаю игнорировать.
После этого достаточно запустить команды versions:display-dependency-updates и versions:display-plugin-updates и получить результаты:
[INFO] The following dependencies in Dependency Management have newer versions:
[INFO] com.amazonaws:aws-java-sdk-core ................. 1.11.221 -> 1.11.237
[INFO] com.amazonaws:aws-java-sdk-dynamodb ............. 1.11.221 -> 1.11.237
[INFO] com.amazonaws:aws-lambda-java-core .................... 1.1.0 -> 1.2.0
[INFO] com.amazonaws:aws-lambda-java-events .................. 2.0.1 -> 2.0.2
[INFO] com.google.guava:guava .......................... 23.3-jre -> 23.5-jre
[INFO] com.google.guava:guava-gwt ...................... 23.3-jre -> 23.5-jre
[INFO] com.google.inject:guice ................................. 3.0 -> 4.1.0
[INFO] io.sentry:sentry-logback .............................. 1.6.1 -> 1.6.3[INFO] The following plugin updates are available:
[INFO] org.codehaus.mojo:sonar-maven-plugin ......... 3.3.0.603 -> 3.4.0.905
[INFO]
[INFO] All plugins have a version specified.Кстати, вторая команда предупредит вас если вы используете какой-то плагин без указания его версии (правда, для этого ее надо запускать на проектных POM‘ах)
Вкратце это всё про «корпоративный» POM. В следующей части я планирую рассказать о типовой структуре проекта и, возможно, о организации деполоя артефактов в центральный и корпоративный репозитории.
Комментарии (35)
insolite
30.11.2017 11:25Чтобы POM не занимал несколько экранов, надо использовать Polyglot Maven.
foal Автор
30.11.2017 11:35Хорошая идея, но есть несколько причин, почему я им пока не пользуюсь. Это поддержка, точнее её отсутствие, в Eclipse. Плюс, как-то у меня не получилось сходу подобрать правильный диалект, который бы мне понравился. Ну и для статьи, по любому, лучше использовать native language, то есть XML.
insolite
30.11.2017 11:47Нравится дело субъективное, но:
dependencyManagement: dependencies: - groupId: org.checkerframework artifactId: checker-qual version: 2.1.10 - groupId: org.checkerframework artifactId: checker version: 2.1.10 - groupId: org.checkerframework artifactId: jdk8 version: 2.1.10
Можно в одну строчку писать, если хочется.
ValDubrava
30.11.2017 14:32Расскажите пожалуйста, какой есть опыт сочетания корпоративного родительского pom и, например, от spring boot?
foal Автор
30.11.2017 14:42Честно говоря — нет у меня такого опыта, первое, что я сделал, когда смотрел на spring boot, это можно ли его использовать без их parent POM. Оказалось, что да, и дальше я не копал :)
ValDubrava
30.11.2017 18:37Можно, но при этом теряются все преимущества «наследования» pom — версии нужно самому проставлять, причем property недоступны.
foal Автор
30.11.2017 19:51Да, есть такая буква. Properry нельзя импортировать. Как и настройки билда, плагинов. А версии то почему нет? С правильного BOM'а подтянутся все версии сами. Надо лишь указать правильную версию самого BOM'а.
DigitalSmile
А зачем, если есть Gradle?
foal Автор
На вкус и цвет все фломастеры разные :) Вот тут мой ответ на твит от @CedricChampeau. Кратко — Maven мне нравится своей стройной моделью проекта. Я считаю, что рамки, которая она накладывает, это плюс, а не минус.
DigitalSmile
Ну на мой взгляд, это как раз не аргумент.
ИМХО, билд скрипты должны быть скриптами, т.е. полноценными программами по сборке. Gradle предоставляет золотую середину между сложностью написания таких скриптов и автоматизированным выполнением рутинных задач.
Maven в свою очередь экстремально декларативен, и если не дай б*г надо что то сделать нестандартное (структура проекта, жизненный цикл сборки и т.п.), то мавен принесет много боли.
Опять же имхо, в 21 веке будущее за гибкостью.
foal Автор
Так, а я о чём? :) Gradle отличный продукт, и не от балды его придумали, а пытаясь решить реальные проблемы. Скорее всего вызванные попыткой «сделать нестандартное». Вот только, для меня сам факт таких проблем, это звоночек, что я делаю, что-то не совсем так и повод решить возникшую проблему немного иначе. A нестандартных подходов я видел много, ещё когда с ANT работал. И всё хорошо, когда сам пишешь этот скрипт, но вот когда его пишет кто-то другой, а тебе надо кусочек поправить. Кто сталкивался, тот поймёт.
DigitalSmile
Так в этом все и дело… Gradle нашел золотую середину и поэтому Maven остается не у дел, как в свое время оставался не удел Ant. Мир меняется, концепция тоже, а мы (разработчики) как двигатели должны использовать самое лучшее что придумано.
Поэтому фраза про фломастеры мне показалось плохим аргументом в пользу мавена. Gradle объективно более удачный инструмент => на него следует переходить и, отдав должные почести, оставить уже мавен в покое.
foal Автор
А… Ну хорошо, что он её нашел. Я же писал, в основном, для тех, кто продолжает «мучиться» с maven по разным причинам. Кому-то он достался в наследство, кто-то сделал осознанный выбор и использует maven или Gradle не потому, что кому-то «должен», а просто потому, что своя голова на плечах есть.
DigitalSmile
Так не интересно, никаких аргументов с вашей стороны нет :(
Приведите, если не трудно, преимущества или недостатки одного над другим.
«Гибкость» в вашем твите это скорее преимущество градла, чем недостаток. Гибкость позволяет сделать то же самое, но с заделом под изменяющиеся условия.
Мне действительно интересно, потому что сталкивался не раз с адептами, которые с пеной у рта доказывают, что лучше мавена ничего нет и не было, и тащат его во все проекты. При этом какой-то внятной позиции добиться не удалось…
Вы не подумайте, я не адепт градла, если завтра выйдет тулза MavGradle, которая будет лучше работать и лучше подходить моим задачам, я стремительно туда перейду. Ну по-моему просто мавен уже морально устарел по приведенным мной выше аргументам.
foal Автор
Ну вот нет у меня этих аргументов. Не сердитесь :) Просто maven это инструмент, который меня пока сильно не подводил. Что бы понять билд чужого проекта надо просто знать мавен, а не заниматься reverse engineering. Я не говорю, о том, как вносить исправления — ведь для этого придётся не просто понять, что делает данный скрипт, но и зачем он это делает, и какая идея за этим стоит.
В то время как у maven модель фиксированная, что значительно облегчает работу с проектами. Опять же юниор на проекте не успееет много сломать. Можно вовремя его поправить.
DigitalSmile
Ну все еще впереди :) Могу описать свои проблемы:
1) Жесткая структура убивает многомодульные проекты со сложной иерархией.
2) Документация в многомодульных проектах генерируется отвратно и слабо настраивается (отчеты checkstyle, PMD, javadoc)
3) Нельзя положить исходники соседнего проекта и организовать билд-цепочку (при изменении в одном модуле ребилдить другой)
4) Нельзя настроить жизненный цикл по своему усмотрению
5) Если надо настроить сложный билд для нескольких языков, приходится юзать Ant с запуском настоящих билд скриптов :)
В моем случае речь не о новичках и сложности при анализе билд-скриптов, а сугубо инженерные проблемы. Хотя если опять же проект достаточно сложный, то читать и анализировать помник на пару тысяч строк, тоже то еще удовольствие…
foal Автор
1. Я возможно вас обижу, наверное, но сложная иерархия в многомодульных проектах часто возникает из-за ошибок проектирования, а с простой иерархией maven справляется на раз.
2. Ничего не могу сказать — вполне возможно, что это и так. Я документацию не генерирую, а когда приходилось по работе (проект из 10-20 модулей) никогда проблем не было. Правда мы её настраивать не пытались :) Результат «из коробки» нас вполне устроил.
3. Не очень понял :) Куда положить? У меня проекты через 2-3 транзитивные зависимости вполне внятно работают с исходниками (для GWT надо) Где организовать? IDE сама разбирается, CI сервер тоже (хотя я это сейчас не использую)
4. Можно, но сложно (очень сложно) — и это плюс IMHO
5. А вот тут я с вами соглашусь, пожалуй. Maven это только для Java.
sshikov
Многие пользователи Flex с вами не согласятся по пункту 5.
axmetishe
Добавлю свои 5 копеек:
1 — практических проблем с многомодульными проектами в Maven нет, могут быть исключительно архитектурные проблемы, но с ними без костыляния и Gradle не справится.
2 — Нет никаких проблем с настройкой документации — тут вам и doxygen для специфичных видов документации, и velocity, и docbook, а оборачивается это все через пару плагинов — javadoc, site-plugin, дальше лишь решаете в каком виде вы получить это хотите.
3 — Весьма сомнительная ситуация, когда вы вместо скомпилированной зависимости проекта хотите использовать ее сборку в процессе билда — если она используется только в текущем проекте, внедрите ее как модуль, если же она используется и в других проектах, наиболее логично будет предоставить ей свой релизный цикл и устанавливать взаимоотношения через бинарные зависимости.
4 — ИМХО lifecycle Maven содержит все возможные стадии жизни исходного кода и отхождение от него также указывает на какую-то архитектурную, либо логическую ошибку в процессе сборки, другой момент, когда вы хотите вместить какую-нибудь специфичную для проекта операцию на той или иной стадии цикла, то вы просто используете фазы сборки. Мне сложно представить ситуацию когда генерация кода должна идти после компиляции, но и это не проблема, перекиньте исполнение плагина на соответствуюшую фазу и вуаля. Кроме того, если уж вам действительно необходимо это сделать, напишите свой плагин и сделайте extend на ту или иную фазу цикла, вот вам и кастомное поведение.
5 — Прекрасно все настраивается, лично писал сборку для SDK под одну платформу, где и C/C++, C#, Android с NDK, lua, Flex и т.д.
На одной из конференций был адвокат Gradle, который 1 час потратил на то, чтобы рассказать какие есть у Gradle рюшечки относительно Maven, но реальных технических оснований для перехода так и не озвучил — вот здесь есть такой красивый отчетик, вот тут оно в демоне собирается(но иногда демон подвисает и его надо жестко убивать). Все то, что он в итоге рассказал в сравнении с Maven реально просто делается и на Maven, на мой прямой вопрос почему он это сделал только с Gradle, ответом было, что он не знал что это можно сделать в Maven.
Как-то я приводил уже на хабре ссылку на проект собираемый Maven с количеством модулей 100+, с документацией, к сожалению, на чистой Java, но приведу еще один раз, на всякий случай — github.com/vporoxnenko/mbsa
P.S. Вы не любите кошек? — Да вы просто не умеете их готовить.
P.P.S. Единственное достоинство Gradle, которое я действительно оценил, это инкрементальная компиляция, которая работала стабильнее чем реализация от takari-lifecycle-plugin пару лет назад.
DigitalSmile
1 — К сожалению есть. Как раз в проектах со сложной иерархией (мой опыт). Кивать на архитектуру, мне кажется, не стоит, именно потому что сам инструмент заставляет использовать жесткое построение модулей. И получается, что инструмент влияет на архитектуру приложения. Градл в свою очередь дает простор для творчества в этом смысле — пиши программу которая соберет твою :)
2 — А вот и есть. Пробовал в многомодульном проекте со сложной иерархией прикрутить site-pulgin в связке с Swagger. Не разрешимая проблема это перекрестные ссылки между модулями по REST API, javadoc и др. Мавен просто не дает таких опций. А если нет сквозной навигации, зачем тогда вообще делать такой плагин?
3 — Почему? У меня есть сторонняя либа, которая разрабатывается соседней командой. Я не хочу поднимать общий мавеновский репозиторий для них, но хочу получать правки по определенным тегам из VCS, чтобы получать нужный мне API.
4 — Я лично с такой проблемой не сталкивался, просто слышал стоны своих коллег :) Однако, я хочу написать свой сборочный шаг (не важно фазу или шаг ЖЦ), чтобы он был написан в виде программы, потому что компиляция сложная для этого проекта. Почему мне советуют писать плагин для системы сборки, это как то неправильно, не находите?
5 — Ага, и что вы использовали из мавеновского арсенала? Вангую, что Ant :)
Адепты тех или иных инструментов есть всегда. Если инструмент может порешать мою боль, я им с радостью воспользуюсь. Мавен тем не менее крут своим репозиторием, тут этого не отнять…
Про проект с 100+ модулей — я открыл корневой помник… 1700 строк… Интересно (без сарказма), как будет выглядеть градловский скрипт сборки.
P.S. я с мавеном жил много много лет, готовить я его умею, но прогресс же не стоит на месте.
axmetishe
5 — maven-nar-plugin, android-maven-plugin, flexmojos-maven-plugin, exec-maven-plugin, ue4-maven-plugin(самописный)
Относительно корневого пома, лишь отчасти согласен, все дело в том, что он передает абсолютно все параметры настройки как плагинов, так и зависимостей, в частности чтобы избежать jar-hell, а также для конфигурации всего проекта из единого файла, и такая конфигурация в Gradle содержала бы не намного меньше параметров и строчек кода и только благодаря прямому указанию параметров в одной строке, например зависимостей, но не более того — я знаю это потому что писал многомодульные проекты как на одном так и на другом.
Обратите внимание лучше на подмодули проекта, например github.com/vporoxnenko/mbsa/blob/master/server/document/pom.xml и его подмодуль github.com/vporoxnenko/mbsa/blob/master/server/document/ui/pom.xml — они достаточно компактны именно благодаря большому корневому pom'у и наследованию параметров от вышестоящих объектов, в компаниях же данную проблему решает superpom, который не было смысла выделять в данном проекте.
Для примера, superpom в моей компании содержит 800 строк, тогда как наследуемые проекты и парент-помы подпроектов компании, благодаря ему не более 300.
sshikov
По пункту 3. — потому что вместе с исходниками соседнего проекта вы хотите притащить в свой еще и знание о том, как их собирать.
В этом месте вы хотите плохого. Не хочу осуждать, потому что для этого надо реально лучше знать ваш проект, но такие желания не следует поддерживать системой сборки.
sshikov
Хм. То есть, писать всю сборку на груви вам не в лом, а написать плагин (по простым правилам) почему-то не нравится? Это как-то неправильно тоже, не находите? Ну или не так — может это и правильно, но в такой формулировке это выглядит как чистая вкусовщина. Все имеют право на то, чтобы выбирать инструмент, но тогда надо так и формулировать — что это вкусы?
insolite
Голословное утверждение. Либо приведите какое-то подтверждение в виде статистики.
Есть куча кейсов, которые простейшим образом покрываются с помощью Maven: добавить зависимости, сконфигурировать плагины, получить свой JAR/WAR и забыть. Причем все это будет в стандартном и понятном каждому виде, а не порождением чьего-то мутного сознания в стиле «привет-Ant».
Нет никакой необходимости в гибкости там, где от нее никакого проку.
DigitalSmile
Ну давайте возьмем несколько первых ссылок в гугле, например dzone.com/articles/gradle-vs-maven
Сравните объем файлов декларативного мавена и процедурного градла по простейшему билду.
insolite
Непонятно, каким образом это подтверждает утверждение «Maven не у дел».
DigitalSmile
Вы вырвали фразу из контекста, перечитайте всю ветку обсуждений
insolite
Причем здесь вся ветка? Я попросил вас обосновать ваше крайне сильное и голословное утверждение. Голословное, т.к. общеизвестно, что несмотря на всю чудесность Gradle и десятилетний возраст этого проекта, adoption у Maven выше в разы и не снижается.
Собственно, наглядная иллюстрация «Maven не у дел»:
DigitalSmile
Вот я же говорю, что вы фразу из контекста выдрали. Я не говорил про долю рынка мавена, а говорил только о наборе функционала и гибкости, и в этом сравнении мавен очевидно проигрывает и, как я выразился, «остается не у дел».
P.S. я к вам в карму не лез, такой ерундой не занимаюсь.
insolite
Инструмент должен решать задачи, адекватным способом, а не предоставлять «набор функционала и гибкости». Проигрывает Maven или не проигрывает это вопрос дискуссионный, а вот то, что он покрывает множество типичных сценариев без какой-либо головной боли – очевидно. Как же очевидно и то, что для некоторых случаев предлагаемый им подход может быть неудобен.
Поэтому я совершенно не понимаю, что должна означать фраза «остается не у дел», когда Maven успешно решает задачи для множества разработчиков и проектов.
sshikov
Еще раз только могу повторить — плагины для мавена пишутся просто. Более того, при большом желании, и небольшими усилиями вы вполне можете притащить в них всю (или почти всю) функциональность плагинов gradle, потому что это не более чем классы. И гибкость тоже никто не ограничивает. Вы вполне можете писать плагины, которым вообще не нужен POM, вы можете брать информацию для сборки откуда угодно, и пользоваться любыми инструментами.
sshikov
Кому они должны, и почему? И вы видимо не слышали про gmaven, например? Там все ровно также, как в gradle (и да, я работал с обоими, если что). И плагины к мавену пишутся вовсе не сложно (и опять же да, я написал с десяток-другой). Нет там никакой боли, воообще. Любая структура проекта, включая никакой (плагины, которым не нужен POM, на минутку, существуют). Все эти сказочки про боль расширения мавена явно написаны теми, кому все равно лень изучить groovy.
knekrasov
Скорость сборки?
DigitalSmile
От версии к версии ситуация улучшается. Могу сказать что за последние полгода-год, градл очень сильно подрос по производительности.