Что лучше maven или gradle
Maven vs Gradle? Это неправильная постановка вопроса
Написать, наконец, этот пост меня заставила уже давняя дискуссия вот к этому посту на тему, которая время от времени всплывает то там, то тут.
Я много раз имел возможность убедиться, что далеко не все одинаково понимают, в чем же состоит декларативность vs процедурность той или иной системы сборки. Основным достоинством инструмента сборки зачастую считается возможность писать алгоритмы сборки на удобном языке. Нужен DSL, никуда без него.
В gradle этот DSL базируется на groovy. sbt использует скалу, leiningen — Clojure, Ant использует xml (совершенно не по делу, кстати). Несложно припомнить системы сборки на базе javascript. Каждый собирает на том языке, который ему ближе. И новые инструменты пишут, например, на котлине.
Увы, но наличие DSL совсем не означает декларативности. Скорее наоборот. В итоге, gradle проект вообще не может полноценно жить без pom.xml. Это шутка, но с большой долей правды. Посмотрите вот сюда: это репозиторий.
Что у нас тут лежит? Да-да, именно pom.xml, он самый. А где же у нас build.gradle? А нет его. Понимаете? Его тут нет.
То есть все метаданные, которые предоставлены о собранном проекте, который заметим, собирается при помощи gradle, состоят только и исключительно из метаданных maven.
Вас это не удивляет? Меня — нисколько. На мой взгляд, gradle, sbt, leiningen и многие другие инструменты почти (или вовсе) не предоставляют метаданных в доступном другим продуктам виде.
Они реально видны только самим себе, и только изнутри процесса сборки. Просто потому, что скрипт сборки — это груви код (Clojure, скала, javascript). Именно поэтому же их так плохо поддерживают IDE (в сравнении с maven или ant, где скрипт это xml). Чтобы понять, что там происходит, нужно выполнить. Нужно иметь gradle внутри, и нужно чтобы gradle отдавал в IDE необходимую информацию.
Как я вижу себе декларативность, и зачем она бывает нужна? В качестве иллюстрации приведу два своих проекта, и один от apache:
Во-первых, мы видим, что с описанием проекта (в моем случае это всегда был pom.xml) иногда бывает нужно и можно работать из любого достаточно развитого языка. Это не обязан быть инструмент сборки, на который изначально расчитан проект.
Во-вторых, если репозиторий спроектирован правильно, в соответствии с принципами REST, то нам не нужен никакой специальный софт для работы с ним, кроме http-сервера. Нужны только данные метауровня чуть выше проекта (список доступных версий, например).
В-третьих, очень удобно то, что важная часть инфраструктуры, в нашем случае plugins, сами просто обычные артефакты, лежат в том же репозитории, и никак не связаны вообще с конкретным проектом.
Вот это я называю декларативным подходом. У нас есть проекты, их много. Они бывают в репозитории, в виде собранных артефактов, в VCS, и еще где-либо, и могут обрабатываться разными инструментами — а не только одним единственным. Дескриптор проекта — это просто файл, любого стандартного и удобного для обработки формата. Репозиторий артефактов — это тоже стандартизованный формат + простой REST API. А логика сборки, на любом удобном вам DSL, лежит отдельно. Хотите — в самом дескрипторе, хотите — в репозитории.
Как бы я вообще это все сделал? В сущности, если брать за основу maven, то сейчас тут не хватает гибкости в части plugins, их настроек, и т.п., потому что существующий xml — это сериализованное представление java-модели данных plugins и ядра, и оно не гибко. Если разработчики решили, что какие-то данные о проекте вам не нужны — у вас остается только вариант key-value в виде properties.
А следовало бы сделать нечто произвольной, но регулярной структуры, ну скажем типа RDF (не обязательно именно его).
Описание проекта в виде RDF сразу позволяет делать полезные вещи вроде поиска в нем, как в базе данных (т.е. репозиторий, в части метаданных, становится просто SPARQL endpoint, и умеет отвечать на поисковые запросы). И такие же запросы можно строить применительно к проекту.
Вот это и был бы истинный poliglot maven. Причем это, кстати, выглядит вполне реализуемо, даже в рамках существующей инфраструктуры.
Инструменты сборки Java: Maven или Gradle
Инструменты автоматизации сборки или инструменты сборки — это приложения, используемые для автоматизации сборки. Автоматизация сборки — важный аспект разработки программного обеспечения. Это относится к процессу автоматизации задач, необходимых для преобразования исходного кода в исполняемые программы. Ваш выбор инструмента сборки будет зависеть от используемых вами языков и фреймворков.
Сегодня мы сосредоточимся на инструментах сборки Java. Java — один из наиболее часто используемых языков при разработке программного обеспечения. Доступно множество инструментов для сборки Java. Мы сравним два самых популярных инструмента сборки для разработки на Java: Maven и Gradle.
Что такое автоматизация сборки?
Автоматизация сборки — это процесс автоматизации задач, необходимых для создания, выполнения и тестирования программ. После того, как вы создадите исходный код для программы, автоматизация сборки вступит в процесс и подготовит исходный код для развертывания в производственной среде.
Автоматизация сборки — это лучшая практика и необходимое условие для любого процесса непрерывной интеграции в DevOps. У большинства современных команд разработчиков есть устоявшийся процесс автоматизации сборки. Эта автоматизация задач помогает сэкономить драгоценное время и ресурсы для разработчиков и групп разработчиков, которые когда-то выполняли эти задачи вручную.
Исторически задачи автоматизации сборки решались с помощью make-файлов. Сегодня они выполняются с помощью средств автоматизации сборки или серверов автоматизации сборки. Термин «автоматизация сборки» может использоваться как синоним «системы сборки».
Что делают инструменты сборки?
Инструменты сборки позволяют решать самые разные задачи автоматизации сборки, в том числе:
Что такое Maven?
Maven, или Apache Maven, был выпущен в 2004 году как усовершенствование Apache Ant. Это инструмент сборки и менеджер проектов на основе XML. Maven — это проект Apache с открытым исходным кодом. Его репозиторий по умолчанию — это центральный репозиторий Maven. Центральный репозиторий состоит из компонентов с открытым исходным кодом от участников, от отдельных разработчиков до крупных организаций. Существует огромное количество плагинов Maven для настройки и расширения функциональности инструмента сборки.
Проекты Maven в первую очередь определяются файлами объектной модели проекта (POM), написанными в XML. Эти файлы POM.xml содержат зависимости проекта, плагины, свойства и данные конфигурации. Maven использует декларативный подход и имеет предопределенный жизненный цикл.
Что такое Gradle?
Gradle был впервые выпущен в 2008 году. Основываясь на концепциях Maven, он был представлен как преемник Maven. Вместо того, чтобы использовать конфигурацию проекта Maven на основе XML, он представил предметно-ориентированный язык (DSL) на основе языков программирования Groovy и Kotlin. Gradle поддерживает репозитории Maven и Ivy для объявления конфигураций проекта. Он был разработан с учетом многопроектных сборок.
Maven или Gradle: сходства
И Maven, и Gradle — бесплатное программное обеспечение с открытым исходным кодом, распространяемое по лицензии Apache License 2.0. Оба они легко настраиваются и поддерживаются различными Java IDE, включая Eclipse.
Больше общего между Maven и Gradle:
Maven или Gradle: различия
Некоторые из ключевых различий между Maven и Gradle:
Maven или Gradle: какой инструмент сборки Java вам подходит?
Выбор инструмента сборки Java во многом зависит от ваших индивидуальных предпочтений и требований проекта.
Вот несколько вещей, которые следует учитывать, если вы выбираете между Gradle и Maven:
Инструменты сборки Java: Ant против Maven против Gradle
В экосистеме JVM доминируют три инструмента сборки:
Муравей с плющом
Ant был первым среди «современных» инструментов сборки. Во многих отношениях он похож на Make. Он был выпущен в 2000 году и за короткий промежуток времени стал самым популярным инструментом сборки для Java-проектов. Он имеет очень низкую кривую обучения, что позволяет любому начать использовать его без какой-либо специальной подготовки. Он основан на идее процедурного программирования.
После первоначального выпуска он был улучшен возможностью принимать плагины.
Основным недостатком был XML как формат для написания скриптов сборки. XML, будучи по своей природе иерархическим, не очень подходит для процедурного подхода к программированию, который использует Ant. Другая проблема с Ant состоит в том, что его XML имеет тенденцию становиться неуправляемо большим при использовании со всеми проектами, кроме очень маленьких.
Основным преимуществом Ant является его контроль над процессом сборки.
специалист
Maven был выпущен в 2004 году. Его целью было улучшить некоторые проблемы, с которыми сталкиваются разработчики при использовании Ant.
Maven продолжает использовать XML в качестве формата для написания спецификации сборки. Однако структура диаметрально отличается. В то время как Ant требует от разработчиков написания всех команд, которые приводят к успешному выполнению какой-либо задачи, Maven опирается на соглашения и предоставляет доступные цели (цели), которые могут быть вызваны. В качестве дополнительного, и, вероятно, наиболее важного дополнения, Maven представил возможность загрузки зависимостей по сети (позже принятую Ant через Ivy). Это само по себе революционизировало способ поставки программного обеспечения.
Однако у Maven есть свои проблемы. Управление зависимостями плохо обрабатывает конфликты между разными версиями одной и той же библиотеки (в этом Айви гораздо лучше). XML как формат конфигурации сборки строго структурирован и стандартизирован. Настройка целей (целей) сложно. Поскольку Maven сфокусирован в основном на управлении зависимостями, сложные, настраиваемые сценарии сборки на самом деле труднее писать в Maven, чем в Ant.
Конфигурация Maven, написанная на непрерывном XML, является большой и громоздкой. В больших проектах он может содержать сотни строк кода, не делая ничего «экстраординарного».
Основным преимуществом Maven является его жизненный цикл. Пока проект основан на определенных стандартах, с Maven можно относительно легко пройти весь жизненный цикл. Это происходит за счет гибкости.
В то же время интерес к DSL (предметно-ориентированным языкам) продолжал расти. Идея состоит в том, чтобы иметь языки, предназначенные для решения проблем, относящихся к определенной области. В случае сборок одним из результатов применения DSL является Gradle.
Gradle
Gradle сочетает в себе хорошие части обоих инструментов и строит поверх них DSL и другие улучшения. Он обладает мощью и гибкостью Ant, а также жизненным циклом Maven и простотой использования. Конечным результатом является инструмент, который был выпущен в 2012 году и привлек много внимания за короткий период времени. Например, Google принял Gradle в качестве инструмента сборки по умолчанию для ОС Android.
Gradle не использует XML. Вместо этого у него был собственный DSL на основе Groovy (один из языков JVM). В результате скрипты сборки Gradle имеют тенденцию быть намного короче и понятнее, чем написанные для Ant или Maven. Объем стандартного кода намного меньше с Gradle, поскольку его DSL предназначен для решения конкретной проблемы: продвижение программного обеспечения через его жизненный цикл, от компиляции до статического анализа и тестирования до упаковки и развертывания.
Русские Блоги
Разница между Maven и Gradle
Предисловие
В мире Java есть три основных инструмента сборки: Ant, Maven и Gradle. После нескольких лет разработки Ant почти исчез, Maven также приходит в упадок, а разработка Gradle бурно развивается. Я имею честь быть свидетелем упадка Maven и подъема Gradle. Основные функции Maven в основном разделены на 5 пунктов: система управления зависимостями, многомодульное построение, согласованная структура проекта, согласованная модель построения и механизм подключаемых модулей. Maven и Gradle имеют свои достоинства в использовании и используют их в соответствии со сценарием использования.
1. Сравнение Maven и Gradle
Maven необходимо ввести зависимость pom.xml
И Gradle представляет build.gradle
Преимущества: Gradle эквивалентен комбинации Maven и Ant.
Недостатки: для ссылок на подклассы микросервисов и мультипроектов он не так хорош, как Maven.
Структура / зависимости проекта определяются файлом pom.xml
Производственный код хранится в src / main / java.
Тестовый код хранится в src / test / java.
Структура / зависимости проекта определяются build.gradle
Производственный код хранится в src / main / java.
Тестовый код хранится в src / test / java.
2. Процесс сборки и жизненный цикл
3. Управление пакетами и транзитивные зависимости
Используйте компонентную систему Ivy, которая является расширенным набором компонентной системы Maven.
Совместим с репозиториями Maven
Когда есть конфликт зависимостей
Конфликт зависимостей Mavenc.png
В крупномасштабных проектах постепенно будут возникать проблемы с производительностью.
Поскольку разработка Maven в основном зависит от поддержки сообщества, больше нет средств для продолжения разработки и поддержки Maven, что приводит к остановке разработки.
Внутри Gradle есть механизм кеширования (когда ввод и вывод файла не изменились, считается, что это неизменный код, а вывод выполняется напрямую. Но когда вы меняете зависимую версию пакета, она иногда не обновляется, что также является проблемой с механизмом кеширования), который будет работать быстрее.
Активная разработка, слишком много версий
Если это полезно для вас, следите за блогом и официальным аккаунтом. Время от времени делитесь новейшими передовыми технологиями и общими технологиями производителей летучих мышей и добавляйте группы, чтобы время от времени делиться живыми лекциями и материалами видеокурсов о крупных коровах в отрасли.
Интеллектуальная рекомендация
Из-за добавления Lombok’s @Accessors (chain = true) класс инструмента копирования bean-компонентов не работает
ПредисловиеСеть Time Novel wap.youxs.org На этот раз был построен новый проект, потому чтоLombok Я привык, но раньше пользовался[email protected]，@AllArgsConstructor，@EqualsAndHashCodeДождитесь очередного коммен.
ios FMDB
1. Что такое FMDB? В iOS использование функций языка C для добавления, удаления, изменения и запроса собственных баз данных SQLite является сложным и хлопотным, поэтому появился ряд библиотек, инкапсу.
POJ2236 WirelessNetWork (также проверьте набор)
Ссылка на заголовок Этот вопрос представляет собой простое приложение параллельного поиска, которое не сложно. (Не потребовалось много времени, чтобы увидеть, что Accepted чувствует себя так хорошо, х.
Android бизнес и реализация SDK интерфейс
Maven vs Gradle? Это неправильная постановка вопроса
Написать, наконец, этот пост меня заставила уже давняя дискуссия вот к этому посту на тему, которая время от времени всплывает то там, то тут.
Я много раз имел возможность убедиться, что далеко не все одинаково понимают, в чем же состоит декларативность vs процедурность той или иной системы сборки. Основным достоинством инструмента сборки зачастую считается возможность писать алгоритмы сборки на удобном языке. Нужен DSL, никуда без него.
В gradle этот DSL базируется на groovy. sbt использует скалу, leiningen — Clojure, Ant использует xml (совершенно не по делу, кстати). Несложно припомнить системы сборки на базе javascript. Каждый собирает на том языке, который ему ближе. И новые инструменты пишут, например, на котлине.
Увы, но наличие DSL совсем не означает декларативности. Скорее наоборот. В итоге, gradle проект вообще не может полноценно жить без pom.xml. Это шутка, но с большой долей правды. Посмотрите вот сюда: это репозиторий.
Что у нас тут лежит? Да-да, именно pom.xml, он самый. А где же у нас build.gradle? А нет его. Понимаете? Его тут нет.
То есть все метаданные, которые предоставлены о собранном проекте, который заметим, собирается при помощи gradle, состоят только и исключительно из метаданных maven.
Вас это не удивляет? Меня — нисколько. На мой взгляд, gradle, sbt, leiningen и многие другие инструменты почти (или вовсе) не предоставляют метаданных в доступном другим продуктам виде.
Они реально видны только самим себе, и только изнутри процесса сборки. Просто потому, что скрипт сборки — это груви код (Clojure, скала, javascript). Именно поэтому же их так плохо поддерживают IDE (в сравнении с maven или ant, где скрипт это xml). Чтобы понять, что там происходит, нужно выполнить. Нужно иметь gradle внутри, и нужно чтобы gradle отдавал в IDE необходимую информацию.
Как я вижу себе декларативность, и зачем она бывает нужна? В качестве иллюстрации приведу два своих проекта, и один от apache:
Во-первых, мы видим, что с описанием проекта (в моем случае это всегда был pom.xml) иногда бывает нужно и можно работать из любого достаточно развитого языка. Это не обязан быть инструмент сборки, на который изначально расчитан проект.
Во-вторых, если репозиторий спроектирован правильно, в соответствии с принципами REST, то нам не нужен никакой специальный софт для работы с ним, кроме http-сервера. Нужны только данные метауровня чуть выше проекта (список доступных версий, например).
В-третьих, очень удобно то, что важная часть инфраструктуры, в нашем случае plugins, сами просто обычные артефакты, лежат в том же репозитории, и никак не связаны вообще с конкретным проектом.
Вот это я называю декларативным подходом. У нас есть проекты, их много. Они бывают в репозитории, в виде собранных артефактов, в VCS, и еще где-либо, и могут обрабатываться разными инструментами — а не только одним единственным. Дескриптор проекта — это просто файл, любого стандартного и удобного для обработки формата. Репозиторий артефактов — это тоже стандартизованный формат + простой REST API. А логика сборки, на любом удобном вам DSL, лежит отдельно. Хотите — в самом дескрипторе, хотите — в репозитории.
Как бы я вообще это все сделал? В сущности, если брать за основу maven, то сейчас тут не хватает гибкости в части plugins, их настроек, и т.п., потому что существующий xml — это сериализованное представление java-модели данных plugins и ядра, и оно не гибко. Если разработчики решили, что какие-то данные о проекте вам не нужны — у вас остается только вариант key-value в виде properties.
А следовало бы сделать нечто произвольной, но регулярной структуры, ну скажем типа RDF (не обязательно именно его).
Описание проекта в виде RDF сразу позволяет делать полезные вещи вроде поиска в нем, как в базе данных (т.е. репозиторий, в части метаданных, становится просто SPARQL endpoint, и умеет отвечать на поисковые запросы). И такие же запросы можно строить применительно к проекту.
Вот это и был бы истинный poliglot maven. Причем это, кстати, выглядит вполне реализуемо, даже в рамках существующей инфраструктуры.