2 что такое система сборки

Build Systems — Intro

Данный пост будет об автоматических системах сборки. Думаю, интуитивно понятно что это и зачем нужно, но для формальности написать нужно — это такие программные продукты, которые на основе некоторой конфигурации могут «собрать» ваш проект.
Под словом «собрать» здесь может скрываться очень обширный объем работы, который при «ручном» подходе требует значительных затрат времени.

загрузить зависимые библиотеки для вашего проекта из сети (репозитория);
скомпилировать классы модуля или всего проекта;
сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
удалять/создавать директории и копировать в них указанные файлы;
упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
установка (deploy) файлов проекта на удаленный сервер;
генерация документации и отчетов.

Путаница

На хабре есть ряд статей о Maven, но, к сожалению, все они находятся в разных хабах, т.к. отдельного хаба для билд систем не существует.
Поэтому, я решил «не быть как все» и выбрать именно общий хаб «Программирование», а не «Java», «Веб-разработка» и др.

Поэтому не заинтересованный читатель может продолжить свой поиск интересного, а заинтересованный — читать далее.

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

В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё время.

High-level архитектура

конфигурации

собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;

парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;

На этом общую часть о build-системах закончу и перейду к более конкретным вещам.

Maven

Так как переписывать то, что написали другие было бы неправильно, поэтому приведу перечень статей по теме, которые уже есть на хабре о Maven и где описано конкретно об этой системе — что это, как работает и на каких принципах основана.

Maven — зачем? — вводная статья о Maven, где описано как устроена конфигурация модуля/проекта, жизненный цикл сборки.
Apache Maven — основы — терминология, установка, сборка, создание проекта из архетипа, полезные ссылки
Maven — автоматизация сборки проекта — более детальное описание жизненного цикла сборки, описание настроек диплоя (deploy), на примере установки для Tomcat сервера.
Создание своих архетипов и каталогов в Maven — для людей уже «в теме» и желающих создавать свои архетипы, если по каким-то причинам не хватает существующих. Процесс описан довольно детально.

Заключение

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

Системы сборки на Java

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

Зачем нужна система сборки

Когда компьютеры только начинали свое существование, системы сборки не были нужны, программы писались под определенные ЭВМ. С развитием индустрии серверы для разработки отделились от промышленных(“продакшен”) серверов, на которых разработанные приложения должны были использоваться.

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

Поэтому и появились системы сборки: они не зависят от IDE и автоматически выполняют действия, перечисленные выше.

Какие бывают системы сборки

Система сборки — это скриптовый код, написанный обычно на определенном языке программирования. Следовательно, для каждого языка они разные. Большинство основаны на самом первом сборщике — Linux-утилите make. Она использует специальные make-файлы, в которых подробно расписаны зависимости файлов друг от друга и порядок их сборки. Этот подход появился еще в 1976 и использовался всеми языками программирования, в том числе Java до разработки собственного средства.

Давайте узнаем подробнее о сборщиках Java.

Первым из них был Apache Ant (Another neat tool). По схеме работы очень похож на утилиту make, но вместо make-файла, состоящего из команд Bash, использует файл формата XML. Вот пример build.xml файла для простого проекта “Hello World”.

Фазы сборки называются целями (). В этом файле их 4: clean, compile, jar и run. Например, при вызове

Сначала отработает clean, который удалит каталог «classes». После этого compile заново создаст каталог, который скомпилируется в папку src, все как определил разработчик. И вообще, поскольку Ant не навязывает никаких соглашений о структуре проекта, программисты сами пишут все команды и определяют порядок сборки.

Что не так?

Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. Здесь все выглядит неплохо, но на промышленный проектах они длинные и неструктурированные, а потому сложны для понимания.

Что привело к появлению новой системы

Apache Maven

Хоть он также использует XML для построения конфигурации (файл называется POM.xml), но имеет серьезные отличия:

1. Здесь есть четкая структура каталогов, и вы обязательно должны ей следовать. (При использовании плагинов IDE, она создается автоматически).Она выглядит вот так:

И если вы, к примеру, поместите файл с тестами в папку с ресурсами, то ваше приложение просто не скомпилируется.

Также у каждого проекта может быть только один файл JAR файл, тогда как при сборке Ant модификации были безграничны: вы вообще можете добавить файл в какую угодно папку, собрать 5 классов в 3 JAR-а и так далее. Все это, безусловно, ухудшало поддерживаемость кода.

2. Автоматическое управление зависимостями

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

3. Стандартизированные названия билдов

Каждый билд имеет атрибуты groupId, artifactId и version. Первые два уникальны и используются для определения в репозитории. Обычно groupId — доменное имя организации, а artifactId — название текущего проекта. Поэтому эта пара и является определяющей: нет двух компаний с одинаковым доменом, как и не существует двух одинаковых проектах в одной компании.

4. Жизненный цикл и плагины

Жизненный цикл maven-проекта — это список фаз, определяющий порядок действий при его построении. Он содержит три независимых порядка выполнения: clean, default и site.

Для расширения и модификации стандартных ЖЦ используются плагины. Ниже представлен пример плагина, который копирует зависимости в ваше директорию.

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

Gradle

Оба, и Ant, и Maven используют XML для конфигурирования сборки. Gradle — предметно-ориентированный язык на основе Groovy. И это его основное отличие от Maven. В остальном Gradle руководствуется теми же принципами. Здесь за выполнение всей работы также ответственны плагины и нет широкой свободы действий.

Приведем пример файла build.gradle для того же проекта с HelloWorld

Gradle распространен в мобильной Android- разработке, а Maven используется в системах управления предприятиями. Почему так? Вопрос остается открытым. Возможно, так просто сложилось. Но Maven все-таки гораздо популярнее на рынке и будет полезен Java-разработчикам в любом случае.

§ 8. Системы сборки кода

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

02 В новых языках программирования (Rust, Go) параллельная сборка и поиск зависимостей уже встроены, но для существующих языков (C, C++, Fortran) это невозможно сделать, поэтому для них используют отдельные системы сборки. Про них и пойдет речь в этой лекции.

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

поиск зависимостей (заголовочных файлов и библиотек),
генерация различных версий кода в зависимости от платформы, на которой происходит сборка,
генерация вспомогательных файлов,
генерация команд для компиляции всех исходный файлов.

04 Как правило, системы сборки поддерживают опции для включения или отключения различных компонент программы. Результатом работы системы сборки является директория, в которой находятся сгенерированные файлы, а также файл с дальнейшими командами для подчиненной (более низкоуровневой) системы сборки. К высокоуровневым системам относятся Autoconf, Cmake, Meson, к низкоуровневым — Make, Ninja. Мы будем изучать Make, Meson и Ninja, а также программу для работы с зависимостями Pkg-config.

Make

05 Классической, а также самой простой системой сборки является GNU Make. Правила сборки для этой системы описываются в файле Makefile , и состоят из списка файлов, которые генерирует (выходные файлы) команда, двоеточия, списка файлов, которые команда использует (входные файлы) для генерации и команд генерации. Если время последнего обновления хотя бы одного входного файла позже времени последнего обновления хотя бы одного выходного файла, то команда выполняется. В противом случае выходные файлы считаются актуальными. Все команды в файле начинаются с символа табуляции.

06 Часто в списке выходных файлов указывают несуществующий файл, тогда команда запускается каждый раз, когда вводится команда make имя-файла . По умолчанию команда make собирает первый файл.

all: echo Hello main.copy: main cp main main.copy

Пример Makefile .

make all # сборка файла all make # сборка файла all make main.copy # сборка файла main.copy

Примеры сборки с помощью Make. Если у вас в директории одновременно находится файла main.cc и main.c , то make выберет только один из них для компиляции.

07 Поскольку Make был разработан для сборки программ, то в него встроены удобные правила для компиляторов, которые работают даже без наличия в директории Makefile . Например, команда make main.o запустит команду компиляции прогаммы $CXX $CXXFLAGS -c -o main.o main.cc . Здесь компилятор и флаги компиляции задаются переменными среды CXX и CXXFLAGS , а входной файл определяется автоматически по названию выходного. Если переменные не определены, то используется компилятор по умолчанию (GCC) и флаги по умолчанию (по умолчанию их нет). Команда make main запустит коману линковки программы $CC $LDFLAGS -o main main.o . Встроенного правила для сборки библиотек в Make нет, но его легко написать самостоятельно.

make main.o # компиляция main.o из main.cc env CXXFLAGS='-O3' make main.o # компиляция main.o из main.cc с максимальным уровнем оптимизации env CXX='clang++' make main.o # компиляция main.o из main.cc с помощью компилятора clang++ make main # линковка main из main.o env CC=g++ LDFLAGS='-flto' make main # линковка main из main.o с флагом оптимизации

Примеры сборки кода с помощью Make.

08 Переменные среды, используемые Make для сборки программ, стали стандартом и для других систем сборки. Практически все системы сборки их поддерживают. Эти переменные чаще всего используются мейнтенерами пакетов для различных дистрибутивов Linux: в этих переменных указываются флаги, которые используются для сборки всех пакетов дистрибутива. Например, в некоторых системах используется флаг -fstack-protector-strong , который позволяет получить защиту от взлома программ даже при наличии в них ошибок работы с памятью.

Переменная	Описание
CC	компилятор языка C и линковщик для всех языков
CFLAGS	флаги компилятора языка C
CXX	компилятор языка C++
CXXFLAGS	флаги компилятора языка C++
FC	компилятор языка Fortran
FFLAGS	флаги компилятора языка Fortran
LDFLAGS	флаги линковщика

Список переменных среды, используемых в Make и других системах сборки.

09 Основным недостатком Make является чрезмерная простота команд: в правилах сборки не учитываются заголовочные файлы, которые включаются в основные файлы с помощью макросов. Это означает, что при изменении заголовочного файла пересборка основного не произойдет. Это послужило причиной создания более совершенных и высокоуровневых систем сборок. Тем не менее, Make до сих пор используется в небольших проектах, в том числе, в проектах, где нужно собирать не код, а что-то другое. Причина этому — простота использования и наличие Make во всех дистрибутивах Linux.

Meson и Ninja

Meson является современной альтернативой Autotools и CMake, основным недостатком которых является использование макросов, а не полноценного языка программирования для описания правил сборки.

10 Любой проект Meson начинается с дерева директорий, в каждой из которых находится файл для сборки. В meson это файл meson.build . В проектах на C++ с небольшими вариациями используется следующее дерево директорий.

doc # документация src ├── test # код модульных тестов │ ├── component1 # структура папок такая же, │ ├── component2 # как и в основном коде │ └── component3 └── myproject # основной код ├── component1 ├── component2 └── component3

Структура проекта.

11 Здесь myproject — название проекта, componentN — логическая единица проекта. Как правило, каждая компонента собирается в отдельную библиотеку (или исполняемый файл), которая затем присоединяется к основному исполняемому файлу. В больших проектах из одной компоненты могут получиться несколько библиотек или исполняемых файлов. При такой схеме название проекта и название компоненты являются частью пути до заголовочного файла, а имя файла совпадает с именем класса, который в нем объявлен. В больших проектах кроме класса в файле могут быть объявлены вспомогательные функции или классы. Чтобы использовать класс Ship из компоненты component1 в каком-либо файле проекта, его следует подключить, используя путь относительно директории src .

#include

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

13 Корневой файл meson.build для вышеописанной упрощенной структуры содержит параметры проекта: название, версию, язык, опции сборки по умолчанию. Команда project должна быть первой командой в корневом файле. Команда subdir исполняет команды из файла meson.build в указанной в качестве аргумента директории.

project( 'myproject', # название проекта 'cpp', # язык version: '0.1.0', # версия кода meson_version: '>=0.50', # минимально поддерживаемая версия Meson default_options: ['cpp_std=c++20'] # используемый стандарт C++ ) subdir('src')

Корневой файл meson.build .

# сохранение пути до текущей директории # для подключения заголовочных файлов # в виде src = include_directories('.') subdir('myproject')

Файл src/meson.build .

myproject_src = files([ 'main.cc' # список исходных файлов ]) executable( 'myproject', # название исполняемого файла include_directories: src, # где ищутся заголовочные файлы sources: myproject_src, # список исходный файлов dependencies: [], # зависимости проекта (если имеются) install: true # устанавливать ли файл )

Файл src/myproject/meson.build .

Для инициализации директории, в которой будет происходить сборка, нужно ввести следующие команды в корне проекта.

meson . build cd build ninja

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

Pkg-config

14 Для того чтобы подключить библиотеку к вашей программе, достаточно указать директорию с заголовочными файлами, директорию с библиотекой, а также название библиотеки с помощью опции -l . Если библиотека установлена в систему стандартным способом, то, как правило, достаточно только названия. Процесс подключения библиотек к проекту автоматизируется с помощью программы pkg-config , которая по названию пакета выдает флаги компилятора и флаги линковщика, которые необходимы для корректной сборки проекта с этой библиотекой.

Команда	Описание
pkg-config —cflags OpenCL	вывести флаги компилятора для подключения библиотеки OpenCL
pkg-config —libs OpenCL	вывести флаги линковщика для подключения библиотеки OpenCL
pkg-config —cflags ‘OpenCL >= 1.2’	вывести флаги компилятора для подключения библиотеки OpenCL версии не ниже 1.2
pkg-config —list-all	вывести список библиотек, установленных в системе и имеющих файл pkg-config

Список команд pkg-config для подключения библиотек.

15 Файл pkg-config для своего проекта обычно делают из шаблона, в котором прописываются директории, в которые устанавливается проект. В Meson это можно сделать автоматически с помощью модуля pkgconfig . Файл установится также автоматически при установке всего проекта.

Name: OpenCL Description: Open Computing Language Client Driver Loader Version: 2.2 Libs: -L/usr/lib64 -lOpenCL Cflags: -I/usr/include

Содержиое файла OpenCL.pc для библиотеки OpenCL.

pkgconfig = import('pkgconfig') pkgconfig.generate( unistdx_lib, version: meson.project_version(), name: 'unistdx', description: 'C++ wrappers for libc', )

Генерация файла unistdx.pc в Meson для проекта Unistdx.

16 Библиотеки также можно автоматически искать с помощью pkg-config . В Meson это команда dependency . В случае с Make команды поиска прописываются в CXXFLAGS и LDFLAGS .

env CXXFLAGS="$(pkg-config --cflags OpenCL)" LDFLAGS="$(pkg-config --libs OpenCL)" make

Подключение библиотеки в Make.

OpenCL = dependency('OpenCL') executable( . dependencies: [OpenCL], . )

Подключение библиотеки в Meson.

Задания

Make 1 балл

17 Напишите Makefile с правилами для сборки программы, состоящей из файлов main.cc и main.hh : первый файл включает второй с помощью #include . Программа должна пересобираться при изменении main.hh . Команды сборки писать не надо, просто укажите зависимости между файлами.

#include "main.hh" int main()  return 0; >

Файл main.cc .

Make + pkg-config 1 балл

18 Соберите код из первого задания с библиотекой zlib. Библиотеку подключите с помощью pkg-config .

Meson 1 балл

19 Соберите код из первого задания с библиотекой zlib с помощью Meson.

Git + Meson 2 балла

20 Скачайте проект unistdx с помощью команды git . Соберите его с помощью Meson с флагами компилятора -march=native -O3 и флагом линковщика -flto .

Системы сборки для Java

Я не совсем понимаю как работает Intellij Idea и как она собирает мою программу. Можно краткий инструктаж в системы сборки и для чего они нужны?
Ещё бы хорошо, если была бы инфа неустаревшая.

Отслеживать
задан 23 фев 2016 в 22:31
Dark Casual Dark Casual
136 1 1 серебряный знак 8 8 бронзовых знаков

А вы для начала попробуйте разработать небольшую программу (типа «Hello world») и собрать проект вручную без IDE. Крайне рекомендую так сделать. Вам это поможет разобраться.

24 фев 2016 в 6:04

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

TL;DR, к сожалению, не получилось.

Система сборки – это программное обеспечение, обеспечивающее автоматизацию сборки проекта. Основное отличие от IDE в том, что конфигурационный файл для системы сборки вы описываете в текстовом виде. Как следствие, быстрее можете начать проект, за счет того, что что все типовые задачи заключаются в копировании уже готовых сниппетов. Это гораздо быстрее, более гибко, мобильно, и, главное, читаемо, чем вводить то же самое через UI диалоги IDE.

Как в общих чертах работает ваша IDE:

Когда вы создаете проект, то IDE определяет некоторые source каталоги, в которых находятся исходные файлы вашего проекта. При запуске проекта эти файлы будут скомпилированы и переместятся в целевую директорию. Все это, как правило, легко меняется. Можно назначить дополнительные source каталоги, в которых IDE будет осуществлять поиск исходных файлов или поменять целевую директорию;
Если ваш проект использует библиотеки, то вы скачиваете их, складываете в определенную директорию, и подключаете их как зависимости вашего проекта. Таким образом IDE оповещается о том, что при запуске проекта, эти JAR-файлы будут находиться в classpath , она сама подставит их в ключ java –cp и начнет предоставлять типы и методы этих библиотек в автодополнении, и делать другие удобные вещи, для которых и предназначены IDE;
Проекту назначается соответствующая JDK, компилятор которой и будет компилировать классы;
Могут назначаться некоторые дополнительные опции, такие как переменные окружения, аргументы JVM и прочее;
IDE также может выполнять определенные задачи. Например, не только положить собранный проект в каталог сборки, или запустить его, но задеплоить его на удаленный сервер;

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

Очевидные недостатки, которые из этого следуют:

если в проекте несколько участников, они все должны использовать одну и ту же IDE и синхронизировать настройки при каждом изменении;
тыкать мышкой в кучу разных диалогов долго и неудобно;

Кроме того, если проект большой, его нужно каким-то образом поделить на модули, а также объявить какой модуль от какого зависит. Машина разработчика — не единственное место где нужно запускать проект — нужны конфигурации проекта для запуска в разных средах: разработка и продакшн, как минимум. Перед сборкой проекта также необходимо запустить интеграционные и юнит- тесты (иногда очень много), чтобы убедиться в отсутствии багов.

Первым для автоматизации этих задач появился Ant. Это аналог make-файла, а по сути набор скриптов (которые называются tasks). Ant – это пример императивного стиля описания сборки проекта. Вы описываете некое действие, например, скомпилировать файлы в директории проекта:

.. потом , скопировать их рабочую директорию

 " includes="**/*.*" excludes="**/*.java"/>

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

Удобно в Ant то, что вы имеете полный и наглядный контроль над сборкой проекта, а неудобно что вы описываете огромное количество очевидных задач, и по прежнему управляете зависимостями проекта вручную (существует возможность подключить Ivy для управления зависимостями).

Если вы хотите именно пошагового понимания, что делает IDE за ширмой — соберите проект с помощью Ant.

Правда жизни состоит в том, что большие проекты используют большое число библиотек, причем библиотека A, от которой зависит ваш проект, может в свою очередь зависеть еще от десяти других, и из этих десяти, половина будет пересекаться с другими зависимостями, от которых зависят ваши библиотеки, включенные в ваш проект 🙂

На смену Ant пришел Maven, который не такой гибкий, но значительно сокращает объем рутинной работы. Основные особенности:

Конфигурация Maven — это один файл pom.xml ;
Из коробки поддерживаются различные типы сборки: JAR, WAR, EAR;
Введена стандартная структура каталогов для проекта. Это сделано для того, чтобы по умолчанию вам не нужно было объяснять системе сборки, где лежат исходные файлы, ресурсы и куда их нужно переместить после компиляции;
Цикл сборки разбит на phases (фазы). Каждая фаза включает в себя определенный стандартный сценарий, который называется goal (цель) . Упрощенно, вы указываете до какой фазы нужно выполнить проект (например, только скомпилировать), и выполняется набор сценариев связанных указанной и предыдущими фазами build lifecycle. Дополнительные сценарии реализуются через плагины к Maven;
Поддерживается модульная архитектура проекта. Можно объявлять зависимости между модулями;
Поддерживаются профили. Это возможность, которая позволяется выполнять сборку проекта для различных окружений (машин) по-разному. Например, в профиле для разработки приложения определяются настройки и плагины, которых нет в профиле для продакшена, и наоборот. Т.е. можно, например, иметь разные настройки для подключения к базе данных для рабочей машины и сервера, где будет разворачиваться приложения. Или добавить профиль для развертывания среды окружения, который содержит только плагины и скрипты, которые подготовят ваше рабочее место при переезде с места на место. Название профиля передается как опция (ключ -P ) к сборке проекта;
Для централизованного хранения библиотек введен центральный репозиторий. Все популярные библиотеки публикуются и периодически обновляются в центральном репозитории. Каждая библиотека уникально идентифицируется по параметрам: groupId, artifactId, version. Вам не нужно скачивать зависимости и хранить их где-то вместе с проектом, они объявляются декларативно в теге dependency и скачиваются автоматически при сборке проекта.

Maven выполняет автоматическое разрешение зависимостей (так называются библиотеки, от которых зависит ваше приложение). Таким образом, например, если библиотека A зависит от библиотеки C, и библиотека B зависит от библиотеки C, но эти C – разных версий, Maven автоматически включит в проект только последнюю версию C (иногда это минус, но все настаивается). Также просто, например, проверить не появились ли новые версии для библиотек, входящих в состав проекта:

Поскольку зависимости выкачиваются автоматически, очень удобно делить проект между участниками команды. Предположите, как-бы вы управляли большим числом зависимостей вручную;

Maven поддерживает архетипы. Это предопределенная структура проекта (шаблон) для быстрого начала разработки приложения. При создании проекта вы можете указать архетип, и вот уже есть некая начальная заготовка. Естественно, можно создавать собственные.

Для Maven есть огромное число полезных плагинов. Основной недостаток, которым ему обычно пеняют, вытекает из его преимуществ. Декларативный стиль описания задач не позволяет так же просто “подшаманить” в определенных случаях, как это делает Ant. Но и это обычно решается через через различные плагины. Например, задачм Ant можно запускать из Maven через antrun-plugin.

Нужно отметить, что когда вы работаете с Maven проектом в IDE, настройки извлекаются именно из Maven. Например, через compiler-plugin проекту указывается версия JDK:

 org.apache.maven.plugins maven-compiler-plugin 1.7 1.7

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

За Gradle не скажу, потому что игрался, но вплотную не использовал.

Резюме: если вы учитесь или делаете тестовый проект без зависимостей на час — IDE нормальный вариант — хотя сейчас все туториалы тоже пишутся под Maven или Gradle. Для остального — система сборки.

Обновление:

Как вам правильно указал @Arsenicum, проект можно собрать и без участия IDE и систем сборки. JDK (Java Development Kit), которое необходимо для разработки, как раз и состоит из виртуальной Java машины (JRE) — это среда исполнения или рантайм, и Development Tools — это инструменты среды разработки.

Development Tools — это набор, в основном, консольных утилит. Они находятся в директории $JAVA_HOME/bin . Полный список тут. Умение напрямую работать с утилитами из набора Basic Tools (особенно jar, java, javac, javadoc), несомненно поможет лучше ориентироваться в вопросах запуска и сборки Java приложений.