Написать код на Java - это еще не все, ведь вам надо после этого его скомпилировать, а после - запустить. А перед этим еще желательно прогнать тесты, понимать где хранить сторонние библиотеки и задаться вопросом - как передать свой код другим людям.
И это - лишь самое малое, с чем можно столкнуться.
Для помощи в решении данных проблем придуманы инструменты сборки.
Представим, что у нас нет никаких инструментов сборки. Как работать?
Самый простейший способ скомпилировать java-код - это вызвать javac.
javac HelloWorld.java Разумеется, тут мы столкнемся с рядом недостатков:
- Невозможно работать с большими проектами - большим количеством файлов.
- Платформозависимость.
- Выполнение тестов затруднено.
- Работа с зависимостями и их версиями осложнена.
Да, мы можем написать некоторые скрипты, которые будут делать многое за нас.
Но главные недостатки такого подхода будут в том, что:
- Никто не застрахован от ошибок в подобных скриптах.
- Нет единого описания процесса сборки.
- Платформозависимость.
Что в общем-то понятно, ведь мы теперь должны не только писать код продукта, но еще и поддерживать наши скрипты в актуальном состянии, реагировать на баги в них. При этом на разных ОС - будут разные скрипты.
Именно поэтому разработали несколько инструментов, которые помогут разработчикам. Самые известные из них для Java, на мой взгляд:
- Ant
- Maven
- Gradle
У каждого есть свои преимущества, однако Ant сейчас уже не так популярен, сильно уступая последним двум. Стандартом для разработки сейчас является либо Maven, либо Gradle, с Ant вы можете столкнуться лишь работая со старыми проектами и старым кодом. Gradle и Maven имеют разницу во взгляде на то, как собирать проект. Gradle основан на графе задач (task), которые могут зависеть друг от друга. Задачи выполняют какую-то работу. Maven же использует модель определённых фаз (phase), к которым присоединяются определённые "цели" (goals). В этих goals и выполняется какая-то работа. Однако, при таких разных подходах обе системы сборки следуют одному соглашению и управление зависимостями происходит схоже.
- Автоматизация действий с кодом там, где мы разрабатываем проект - на вашей локальной машине.
- Автоматическое управление зависимостями.
- Четкий жизненный цикл - наиболее распространенные действия должны быть легко доступны.
- Соглашения о версионировании
- Соглашение о расположении кода и структуре проекта
- Вместе с Maven к нам пришли четкие рекомендации расположения тестов, кода, зависимостей, ресурсов и т.д
- Появился четкий жизненный цикл каждой цели: цель для компиляции, цель для сборки и т.д
- Локальный репозиторий для хранения зависимостей
- Понятия версионного кода - релизы, снэпшоты
- Многомодульность
- Декларативный подход
- Модульная структура - поддержка плагинов для выполнения задач
Благодаря модульности получается, что maven - это небольшое ядро, а все остальное - это некоторые плагины, которые делают работу.
Создание проекта по шаблону:
mvn archetype:generate
//todo
build plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<!-- DO NOT include log4j.properties file in your Jar -->
<excludes>
<exclude>**/log4j.properties</exclude>
</excludes>
<archive>
<manifest>
<!-- Jar file entry point -->
<mainClass>utils.filesystem.DirectoryUtils</mainClass>
</manifest>
</archive>
</configuration>
</plugin>
//todo
Пропустить тесты
clean install -Dmaven.test.skip