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
Генерация файла unistdx.pc в Meson для проекта Unistdx.
16 Библиотеки также можно автоматически искать с помощью pkg-config . В Meson это команда dependency . В случае с Make команды поиска прописываются в CXXFLAGS и LDFLAGS .
env CXXFLAGS="$(pkg-config --cflags OpenCL)"LDFLAGS="$(pkg-config --libs OpenCL)" make
17 Напишите Makefile с правилами для сборки программы, состоящей из файлов main.cc и main.hh : первый файл включает второй с помощью #include . Программа должна пересобираться при изменении main.hh . Команды сборки писать не надо, просто укажите зависимости между файлами.
#include"main.hh"intmain()return0;>
Файл 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 .
2 что такое система сборки
Система сборки — программа, с помощью которой можно собрать программу.
Обычно компиляция состоит из нескольких сложных этапов со всякими флагами и и разными зависимостями. Система сборки помогает их решать.
Системы сборки можно разбить на две больших категории:
Системы сборки общего назначения;
Системы сборки для конкретных языков программирования;
Системы сборки общего назначения §
Предзначены для сборки любого ПО.
Вот некоторые из наиболее популярных систем сборки:
Системы сборки для конкретных языков программирования §
Отдельно можно выделить системы сборки, специфичные для конкретных языков программирования. Они предназначены для упрощения процесса компиляции и сборки проектов, написанных на определённых языках программирования.
Вот некоторые из наиболее популярных систем сборки для различных языков программирования:
1. Maven и Gradle (Java) §
Описание: Maven и Gradle — это системы сборки для Java, которые обеспечивают управление зависимостями, стандартизацию проектов и поддержку автоматизации сборки.
Преимущества: Они предлагают гибкую конфигурацию проектов, интеграцию с различными IDE и поддержку множества плагинов.
2. MSBuild (C#/.NET) §
Описание: MSBuild — это система сборки, используемая в Visual Studio для проектов на платформе .NET.
Преимущества: Она тесно интегрирована с Visual Studio, поддерживает различные типы проектов .NET и позволяет настраивать процессы сборки.
3. Cargo (Rust) §
Описание: Cargo — это система сборки и менеджер пакетов для языка программирования Rust.
Преимущества: Cargo упрощает управление зависимостями, компиляцию проектов и публикацию библиотек.
4. Mix (Elixir) §
Описание: Mix — это инструмент для создания, компиляции и тестирования программ на языке Elixir.
Преимущества: Он предоставляет удобный способ управления проектами Elixir, включая управление зависимостями и интеграцию с Hex, менеджером пакетов Elixir.
5. Xcode Build System (Swift/Objective-C) §
Описание: Встроенная система сборки в Xcode, используемая для разработки приложений на Swift и Objective-C для iOS и macOS.
Преимущества: Тесная интеграция с Xcode IDE, поддержка различных целей сборки и конфигураций.
6. Webpack и Babel (JavaScript) §
Описание: Webpack и Babel — это инструменты, используемые в современной веб-разработке для сборки и транспиляции JavaScript-кода.
Преимущества: Они позволяют оптимизировать веб-приложения, управлять зависимостями и использовать новейшие возможности JavaScript.
2. Используйте автоматические системы сборки программ
Нажимайте на одну (единственную) кнопку: используйте полностью автоматизированные («в одно действие») системы, которые собирают весь проект без вмешательства пользователя.
Процесс сборки программы «в одно действие» очень важен. Он должен давать надежный и воспроизводимый результат трансляции ваших исходных файлов в распространяемый пакет. Имеется богатый выбор таких автоматизированных инструментов сборки, так что нет никакого оправдания тому, что вы их не используете. Выберите один из них и применяйте его в своей работе.
Мы встречались с организациями, где подобное требование игнорировалось. Некоторые полагают, что настоящий процесс сборки должен состоять в том, чтобы пощелкать мышью там и сям, запустить пару утилит для регистрации серверов COM/CORBA и вручную скопировать несколько файлов. Вряд ли у вас есть лишнее время и энергия, чтобы растрачивать их на то, что машина сделает быстрее и лучше вас. Вам нужна надежная автоматизированная система сборки программы «в одно действие».
Успешная сборка должна происходить молча, без каких бы то ни было предупреждений (см. рекомендацию 1). Идеальный процесс сборки должен выдать только одно журнальное сообщение: «Сборка успешно завершена».
Есть две модели сборки — инкрементная и полная. При инкрементной сборке компилируются только те файлы, которые претерпели изменения со времени последней инкрементной или полной сборки. Следствие: вторая из двух последовательных инкрементных сборок не должна перезаписывать никакие файлы. Если она это делает — по всей видимости, у вас в проекте имеется циклическая зависимость (см. рекомендацию 22), либо ваша система сборки выполняет ненужные операции (например, создает фиктивные временные файлы, чтобы затем просто удалить их).
Проект может иметь несколько видов полной сборки. Рассмотрите возможность параметризации процесса сборки при помощи таких важных параметров, как целевая архитектура, отладочная или коммерческая версии, вид пакета (программа-инсталлятор или просто набор файлов). Одни установки сборки могут давать только наиболее существенные исполнимые и библиотечные файлы, другие — добавлять к ним вспомогательные файлы, а окончательная сборка — создавать программу-инсталлятор, которая включает в себя все ваши файлы, файлы сторонних производителей и код инсталляции.
Со временем размер проекта обычно возрастает, растет и стоимость отказа от автоматизированной системы сборки. Если вы не используете ее с самого начала, вы теряете время и ресурсы. Все равно со временем потребность в такой системе станет непреодолимой, но при этом вы окажетесь под гораздо большим давлением, чем в начале проекта.
В больших проектах возможна даже специальная должность «хозяина сборки», который отвечает за работу этой системы.
4. Пакеты (сборки) системы Tor Программное обеспечение Tor разрабатывается для различных операционных систем: — ОС семейства Microsoft Windows — ОС семейства Linux/Unix- ОС Apple- и для смартфонов (ОС Android, iPhone, iPad и др.)Для каждой из операционных систем существуют различные варианты
6.2. Работа со службами с помощью программ операционной системы
6.2. Работа со службами с помощью программ операционной системы Естественно, что со службами можно работать не только с помощью реестра , но и используя специальные стандартные программы операционной системы Windows Vista. Одну из таких программ мы уже рассмотрели. Это оснастка
Приложение Б. Общие параметры программ для системы X Window
Приложение Б. Общие параметры программ для системы X Window Каждая программа, предназначенная для работы в системе X Window, имеет параметры, представленные в табл. Б.1.Параметры программ X Window Таблица Б.1 Параметр Описание -background <red|green|blue> Устанавливает цвет фона -background
Вариант 1 – Автоматические тексты
Вариант 1 – Автоматические тексты Есть полуавтоматические способы создания текстовой информации. Их плюс в том, что для Google и Яндекс они будут уникальными Это быстро и относительно недорого Здесь вы берете количеством. Минус – контент получится достаточно «мусорным» и
Автоматические транзакции
Автоматические транзакции Для разрешения провайдеру самостоятельно управлять транзакциями нужно указать в строке инициализации параметр «auto_commit=true»:Call сn.Open(«data source=localhost:d:databaseemployee.gdb;auto_commit=true»,»gamer», «vermut»)В этом случае все создаваемые объекты сессий для данного источника
Автоматические отступы
Автоматические отступы Чтобы до минимума уменьшить объем выполняемой вами работы, редактор Visual Basic автоматически устанавливает отступ в новой строке, равный отступу в предыдущей. Если в новой строке отступ должен быть меньше, просто нажмите клавишу удаления символа
Автоматические переменные
Автоматические переменные По умолчанию переменные, описанные внутри функции, являются автоматическими. Можно, однако, это подчеркнуть явно с помощью ключевого слова auto:main( )
8.3.1. Автоматические объекты
8.3.1. Автоматические объекты Автоматический объект размещается в памяти во время вызова функции, в которой он определен. Память для него отводится из программного стека в записи активации функции. Говорят, что такие объекты имеют автоматическую продолжительность
8.3.2. Регистровые автоматические объекты
8.3.2. Регистровые автоматические объекты Автоматические объекты, интенсивно используемые в функции, можно объявить с ключевым словом register, тогда компилятор будет их загружать в машинные регистры. Если же это невозможно, объекты останутся в основной памяти. Индексы
Автоматические индексы в сравнении с определенными пользователем индексами
Автоматические индексы в сравнении с определенными пользователем индексами Firebird автоматически создает индексы для обеспечения различных ограничений целостности (более подробную информацию см. в главах 16 и 17). Для удаления таких индексов необходимо удалить
Выбор дополнительных программ и компонентов системы
Выбор дополнительных программ и компонентов системы После того как разметка диска окончена, программа установки может спросить, какие дополнительные программы или компоненты системы нужно устанавливать, а какие нет. Здесь возможны следующие варианты.Если вы
6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ
6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ Программная система может состоять из отдельных разработанных разными организациями выполняемых программ. Объединение функций этих программ в целую единую программу может привести к нехватке оперативной памяти машины, а сама
6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ
6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ Резидентная программа — программа, которая постоянно находится в оперативной памяти машины и не препятствует запуску новых программ. После запуска резидентная программа становится как бы частью операционной системы MS DOS
6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ
6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ Такой обмен обычно реализуется при многопроцессорной (многомашинной) обработке. Порт каждой из программ представляет программу накопления и верификации как входных, так и выходных данных в соответствующих
Системы сборки для 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:
Все 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 приложений.