Где хранятся скомпилированные maven ом файлы проекта

Этот урок освещает создание вами простого Java-приложения с использованием Maven.

Что вы создадите

Вы создадите простое приложение и соберете его с помощью Maven.

Что вам потребуется

Примерно 15 минут свободного времени
Любимый текстовый редактор или IDE и выше

Как проходить этот урок

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

Чтобы начать с нуля, перейдите в Настройка проекта.

Когда вы закончите, можете сравнить получившийся результат с образцом в gs-maven/complete .

Настройка проекта

Для начала вам необходимо настроить Java-проект перед тем, как собрать его Maven’ом. Т.к. урок посвящен Maven, сделаем проект максимально простым, насколько это возможно.

Создание структуры каталогов

В выбранном вами каталоге проекта создайте следующую структуру каталогов; к примеру, командой mkdir -p src/main/java/hello для *nix систем:

Внутри src/main/java/hello директории вы можете создать любые Java-классы, какие вы хотите. Для простоты и согласованности с остальной частью урока, Spring рекомендует вам создать два класса: HelloWorld.java и Greeter.java .

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

Распакуйте архив и добавьте путь к каталогу bin в переменную окружения path.

Чтобы протестировать правильность установки Maven, запустите в командной строке:

Теперь у вас есть установленный Maven.

Создание простой сборки Maven

Теперь, когда Maven установлен, вам необходимо создать определение Maven-проекта. Maven-проекты определяются как XML-файлы с названием pom.xml. Помимо всего прочего, этот файл определяет имя проекта, версию, а также зависимости от сторонних библиотек.

Создайте файл с названием pom.xml в корневом каталоге проекта и наполните его следующим содержанием:

За исключением дополнительного элемента , это простейший из pom.xml файлов, необходимый для сборки Java проекта. Он включает следующие детали конфигурации проекта:

— версия POM-модели (всегда 4.0.0)
— группа или организация, к которой принадлежит проект. Чаще всего выражается в виде перевернутого наоборот доменного имени
— имя, которое будет передано библиотеке экземпляра(artifact) проекта (к примеру, имя его JAR или WAR файла)
— версия, с которой будет собран проект
— как проект должен быть упакован. По умолчанию, с «jar» упаковывается в JAR-файл, «war» — WAR-файл

На данном этапе мы имеем минимальное, но уже рабочее определение Maven-проекта.

Сборка Java кода

Теперь все готово для сборки проекта Maven’ом. Вы можете выполнить несколько этапов жизненного цикла сборки, включая компиляцию кода, создание библиотеки пакета(такого, как JAR-файл) и установку библиотеки в локальный репозиторий Maven зависимостей.

Попробуйте собрать, выполнив команду, приведенную ниже:

Этим вы запустите Maven, передав ему указание на выполнение задачи compile. Когда он закончит, вы должны найни скомпилированные .class файлы в target/classes директории.

Вряд ли вы захотите распостранять или работать напрямую с .class файлами, поэтому вам полее подойдет выполнение задачи package:

Задача package включает компиляцию вашего Java кода, запуск тестов, а в конце упаковывает в JAR-файл в target директории. Название JAR-файла будет основано на и . К примеру, с минимальным pom.xml(см. выше), JAR-файл будет иметь название gs-maven-initial-0.1.0.jar.

Если вы изменили значение с «jar» на «war», то результатом будет WAR-файл в target директории вместо JAR-файла.

Maven также хранит репозиторий зависимостей на вашей локальной машине(обычно в .m2/repository директории в вашей домашней папке) для быстрого доступа к зависимостям проекта. Если вы хотите добавить JAR-файл вашего проекта в локальный репозиторий, тогда вам необходимо выполнить задачу install :

Задача install включает компиляцию, тестирование, упаковку кода проекта, а затем копирование в локальный репозиторий, тем самым другие проекты смогут ссылаться на него как на зависимость.

Говоря о зависимостях, пришло время объявлять зависимости в Maven сборке.

Объявление зависимостей

Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек. Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или сложного функционала.

К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время. Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это и другими интересными способами, например с помощью Joda Time библиотеки.

Для начала, изменим HelloWorld.java , как показано ниже:

Здесь HelloWorld использует Joda Time LocalTime класс для получения и печати текущего времени.

Этот блок XML объявляет список зависимостей проекта. В частности, он объявляет единственную зависимость от Joda Time библиотеки. В элементе, зависимость определяется через описание трех вложенных элементов:

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

По умолчанию, все зависимости определены как зависимости. Т.е. они должны быть доступны во время компиляции(а если вы собираете WAR-файл, то в /WEB-INF/lib каталоге). Кроме того, вы можете добавить элемент, с одним из значений:

provided — зависимости, которые требуются для компиляции кода проекта, но которые будут доступны во время выполнения кода контейнером(например, Java Servlet API)
test — зависимости, которые используются для компиляции и запуска тестов, но не требуемые для сборки или выполнения кода проекта

Сейчас, если вы выполните mvn compile или mvn package , Maven должен будет разрешить Joda Time зависимость из Maven Central репозитория и успешно собрать проект.

Здесь полная версия pom.xml :

Полная версия pom.xml использует Maven Shade Plugin как удобный инструмент для создание выполняемого JAR-файла. Целью данного урока является показать, как начать работать с Maven, не используя, в частности, этот плагин.

Поздравляем! Вы создали простой, но эффективный файл сборки Maven для сборки Java проектов.

Для начала нужно установить Maven, скачав его по этой ссылке.

Далее необходимо распаковать скачанный архив и установить переменной окружения M2_HOME ссылку на местонахождение распакованного архива. Например, C:\Program Files\maven\

Чтобы проверить, что все установилось, в командной строке пропиши:

Если отобразится информация о версии Maven, Java и т.д., все готово к работе.

Теперь открой IntelliJIDEA и создай новый проект. В первом же окне выбери Maven:

Нажми Next и заполни следующее диалоговое окно:

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

После того, как проект создался, обрати внимание на его структуру:

в папке src/main/java содержатся java-классы;
в src/main/resources — ресурсы, которые использует наше приложение (HTML-страницы, картинки, таблицы стилей и тд);
src/test — для тестов.

Управление зависимостями в Maven

На сайте библиотеки. Если нам нужен Apache Commons IO, переходим на официальный сайт, выбираем вкладку Dependency Information. Здесь есть вся необходимая информация — ее можно просто скопировать и добавить в наш раздел dependencies.

В Maven-репозитории. В поиске введи “apache commons io”, и ты увидишь все доступные версии библиотеки. После выбора нужной, просто скопируй:

и добавь в свой pom.xml.

Виды Maven-репозиториев

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

Сборка Java-проекта с помощью Maven

clean — удаляются все скомпилированные файлы из каталога target (место, в котором сохраняются готовые артефакты);
validate — идет проверка, вся ли информация доступна для сборки проекта;
compile — компилируются файлы с исходным кодом;
test — запускаются тесты;
package — упаковываются скомпилированные файлы (в jar, war и т.д. архив);
verify — выполняются проверки для подтверждения готовности упакованного файла;
install — пакет помещается в локальный репозиторий. Теперь он может использоваться другими проектами как внешняя библиотека;
site — создается документация проекта;
deploy — собранный архив копируется в удаленный репозиторий.

через командную строку:

используя Intellij IDEA:

Часть 4. Основы Maven - 7

До запуска package выполняются фазы validate, compile, test. Исключение — фаза clean. Ее желательно вызывать перед каждой новой сборкой проекта. Фазы можно перечислить через пробел:

После публикации топика о Maven в комментариях возникли вопросы о том, как начать с ним работать, с чего начать, как составлять файлы pom.xml, откуда брать плагины и т.п. Данный топик будет своего рода getting started или f.a.q.

Как в любой системе, в Maven, есть свой набор терминов и понятий.

Вся структура проекта описывается в файле pom.xml (POM – Project Object Model), который должен находиться в корневой папке проекта. Ключевым понятием Maven является артефакт — это, по сути, любая библиотека, хранящаяся в репозитории. Это может быть какая-то зависимость или плагин.

Зависимости — это те библиотеки, которые непосредственно используются в вашем проекте для компиляции кода или его тестирования.

Плагины же используются самим Maven’ом при сборке проекта или для каких-то других целей (деплоймент, создание файлов проекта для Eclipse и др.).

В самом начале работы с Maven, пользователь непременно столкнется с таким понятием как архетип. Архетип — это некая стандартная компоновка файлов и каталогов в проектах различного рода (веб, swing-проекты и прочие). Другими словами, Maven знает, как обычно строятся проекты и в соответствии с архетипом создает структуру каталогов.

Как правило, название артефакта состоит из названия группы, собственного названия и версии. К примеру Spring будет иметь вот такое название в среде Maven: org.springframework.spring:2.5.5. Последний домен означает всегда artifactId, все, что перед ним – groupId – хорошо это запомните!

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

Последнюю версию всегда можно скачать на странице загрузки на официальном сайте. Просто распаковываем архив в любую директорию. Далее необходимо создать переменную в Path, в которой необходимо указать путь к Maven. Заходим в Win + Pause – Дополнительно – Переменные среды – в верхнем окошке нажимаем Создать, вводим имя M2_HOME и значение допустим “C:\apache-maven-2.2.1”. Далее там же создаем еще одну переменную M2 со значением %M2_HOME%\bin. Так же убеждаемся, что есть переменная JAVA_HOME с путем к JDK. Ее значение должно быть примерно таким «c:\Program Files\Java\jdk1.6.0_10\». И наконец в том же окошке создаем/модифицируем переменную Path, в нее необходимо просто написать %M2%, чтобы наша папочка с исполняемым файлом Maven была видна из командной строки. Теперь необходимо проверить работоспособность нашей установки. Для этого заходим в командную строку и вводим команду

Должна появиться информация о версиях Maven, jre и операционной системе, что-то вроде:

Maven создаст вам локальный репозиторий в вашей личной папке, например в каталоге C:\Documents and Settings\username\.m2\repository

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

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

Итак, допустим нас интересует веб-приложение – находим подходящий архетип, называется он maven-archetype-webapp. В командной строке, в необходимом каталоге выполняем команду Maven:

Теперь мы можем лицезреть довольно наглядную структуру каталогов с говорящими названиями java – здесь будут ваши классы, webapp – здесь размещаются странички веб-приложения, resources – различного рода ресурсы в classpath (файлы конфигурации, например), test – юнит-тесты, соответственно и т.п.

Здесь все просто – выполняем команду

в корневом каталоге приложения, там, где находится файл pom.xml. Первая команда скомпилирует ваш проект и поместит его в папку target, а вторая еще и положит его к вам в локальный репозиторий.

Есть полезная функция, наподобие конвеера, то есть можно написать

и Maven сначала очистит папку target проекта, потом соберет его и положит в репозиторий.

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

Как правило, большинство популярных библиотек находятся в центральном репозитории, поэтому их можно прописывать сразу в раздел dependencies вашего pom-файла. Например чтобы подключить Spring Framework необходимо определить следующую зависимость:

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

Специфические вещи обычно не находятся в центральном репозитории и тогда вам придется указать репозиторий производителя вручную. Для примера добавим зависимость JSF-фреймворка ajax-компонентов JBoss RichFaces.

С зависимостями все просто:

А вот репозиторий JBoss теперь необходимо прописать ручками либо в файле settings.xml, который лежит в корне вашего локального репозитория, либо в самом файле pom.xml, в зависимости от того, нужен ли данный репозиторий во всех проектах, либо в каком-то одном конкретном, соответственно:

Последний параметр чаще всего имеет значение jar.

Так как плагины являются такими же артефактами, как и зависимости, то они описываются практически так же. Вместо раздела dependencies – plugins, dependency – plugin, repositories – pluginRepositories, repository – pluginRepository.

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

Посмотрим как настроить плагин для создания проекта для Eclipse с использованием WTP ver. 2.0. В раздел plugins нашего pom.xml прописываем следующий плагин:

Теперь идем опять таки в командную строку и выполняем команду

Ждем пока Maven найдет все библиотеки в репозитории или скачает их и вуаля – теперь наш Maven-проект можно открыть как проект eclipse. При этом библиотеки никуда не копируются как при классическом подходе, а остаются в репозитории и Eclipse делает на них ссылку через свои переменные.

Единого списка всех плагинов естественно не существует, на официальном сайте только есть поддерживаемые плагины непосредственно разработчиками Maven. Однако хотелось бы отметить, что названия плагинов довольно прямолинейны и сделав поиск по ключевым словам «maven tomcat plugin» вы скорее всего обнаружите первой ссылкой плагин для деплоймента проекта в Tomcat.

К сожалению сам не имею большого опыта настройки репозитория, но могу посоветовать как наиболее простой и распространенный Nexus. За дополнительной информацией следует обратиться на сайт данного проекта.

Однако нельзя оставить без внимания и достойных конкурентов в лице Artifactory и Archiva.

Что такое Maven?

maven

Здесь есть определенные термины, которые могут быть для вас новыми.

Как установить?

Вам необходимо выполнить следующие простые шаги:

В вашей системе должна быть установлена Java.
Задайте переменную среды Java.
Загрузите Maven.
Теперь вам нужно распаковать zip-архив Maven в желаемое место.
Добавьте каталог bin созданного вами каталога, то есть apache-maven-3.5.3 (независимо от установленной вами версии), в переменную среды PATH и системную переменную.
Теперь откройте cmd и запустите команду mvn -v
Если на вашем экране отображается снимок экрана, показанный ниже, значит, процесс установки завершен.

Файл Maven pom.xml

POM означает объектную модель проекта. Файл pom.xml содержит информацию о проекте и информацию о конфигурации для сборки проекта. Он содержит зависимости, каталог сборки, каталог с исходным кодом, каталог с исходным кодом теста, плагин и т. д. Maven просматривает файл pom.xml, а затем выполняет цель. Для создания простого файла pom.xml вам потребуются следующие элементы:

project: Корневой элемент файла pom.xml.
groupId: вложенный элемент проекта. Он описывает идентификатор проекта.
modelVersion: вложенный элемент проекта. Он сообщает вам версию модели.
artifactId: вложенный элемент проекта. В нем указывается идентификатор проекта. Артефакт либо создается, либо используется проектом. Примеры артефактов: JAR, исходные и двоичные дистрибутивы, а также WAR.
Version: Подэлемент проекта. Он сообщает вам версию артефакта в данной группе.

Ниже показан образец файла pom.xml:

В файле pom.xml есть некоторые дополнительные элементы:

Packaging: определяет тип упаковки, такой как war, jar и т. д.
Scope: определяет область для проекта maven.
Url: указывает URL-адрес проекта.
Name: определяет имя проекта maven.
Dependency: определяет зависимость. Он используется внутри зависимостей.

Пример кода файла pom.xml, показывающий дополнительные элементы:

Репозиторий

Локальный

Центральный

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

Удаленный

Читайте также:

Ведьмак 3 как использовать адреналин в бою ps4
Что лучше chrome или mi browser
Когда выйдет playstation 11
Модификации операционной системы твики мешающие или отключающие записи в активность компьютера
Почему скайп каждый раз устанавливается заново

Apache Maven — основы

Терминология

Как в любой системе, в Maven, есть свой набор терминов и понятий.

Вся структура проекта описывается в файле pom.xml (POM – Project Object Model), который должен находиться в корневой папке проекта. Ключевым понятием Maven является артефакт — это, по сути, любая библиотека, хранящаяся в репозитории. Это может быть какая-то зависимость или плагин.

Зависимости — это те библиотеки, которые непосредственно используются в вашем проекте для компиляции кода или его тестирования.

Плагины же используются самим Maven’ом при сборке проекта или для каких-то других целей (деплоймент, создание файлов проекта для Eclipse и др.).

В самом начале работы с Maven, пользователь непременно столкнется с таким понятием как архетип. Архетип — это некая стандартная компоновка файлов и каталогов в проектах различного рода (веб, swing-проекты и прочие). Другими словами, Maven знает, как обычно строятся проекты и в соответствии с архетипом создает структуру каталогов.

Установка Maven

mvn –version

Должна появиться информация о версиях Maven, jre и операционной системе, что-то вроде:

Maven version: 2.2.1 Java version: 1.6.0_10 OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"

Maven создаст вам локальный репозиторий в вашей личной папке, например в каталоге C:\Documents and Settings\username\.m2\repository

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

Создание приложения из архетипа

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

Сборка проекта

Здесь все просто – выполняем команду

mvn package

mvn install

Есть полезная функция, наподобие конвеера, то есть можно написать

mvn clean install

и Maven сначала очистит папку target проекта, потом соберет его и положит в репозиторий.

Зависимости и репозитории

 . org.springframework spring 2.5.5

С зависимостями все просто:

  org.richfaces.ui richfaces-ui 3.3.1.GA

    true  false never  repository.jboss.com Jboss Repository for Maven http://repository.jboss.com/maven2/ default

Как правило на сайтах крупных проектов пишут всю информацию, необходимую для встраивания их библиотеки в проект на основе Maven, но бывают случаи, когда артефакт приходится искать очень и очень долго. Здесь нам очень сильно может помочь MVNrepository.com — он вам всегда подскажет где может находиться искомая библиотечка. Но если уж и там не нашлось, то из собственного опыта могу посоветовать гуглить « pom.xml». Бывает так, что проекты уже давно закрыты и в репозитории не положены потому что разработчики уже не заботятся об их распространении. Тогда остается один единственный способ – добавить файл в репозиторий вручную командой:

mvn install:install-file -Dfile= -DgroupId= -DartifactId= -Dversion= -Dpackaging=

Последний параметр чаще всего имеет значение jar.

Плагины

 org.apache.maven.plugins maven-eclipse-plugin 2.0

Теперь идем опять таки в командную строку и выполняем команду

mvn eclipse:eclipse

Собственный репозиторий

Однако нельзя оставить без внимания и достойных конкурентов в лице Artifactory и Archiva.

Заключение

Очень надеюсь, что цель данной статьи достигнута – минимальных знаний по Maven должно хватить на работу с не очень большими проектами. Для более серьезных целей очень советую детально изучить maven-compiler-plugin и maven-resource-plugin – они напрямую отвечают за конечную компоновку проекта. Я считаю, что самым главным моментом в обучении Maven является понимание идеологии – Maven описывает конечную структуру проекта, а не пути к ее достижению, в отличие от Ant.
Полезные ссылки
Официальная страница Maven
Документация
Центральный репозиторий
Репозиторий iBiblio
Поиск артефактов по названию
Неплохой форум по Maven
Maven: The Definitive Guide — хорошая книга по Maven

Сборка Maven-проекта

Структура проекта описывается в файле pom.xml, который должен находиться в корневой папке проекта. Содержимое проектного файла имеет следующий вид:

Java-университет

Не все секции могут присутствовать в описании pom.xml. Так секции properties и repositories часто не используются. Параметры описания текущего проекта являются обязательными . Про последнюю секцию мы сейчас и поговорим.

Секция build

Секция build не является обязательной – Maven умеет собирать проект и без нее. Но если ты хочешь настроить сборку более-менее сложного проекта, то понимание как там все устроено тебе пригодится.

Давай рассмотрим простой пример:

projectName
$/src/java
$/targetDir

$/src/java/resources

**/*.properties

. . .

Данная секция содержит основную информацию по сборке: где расположены Java-файлы, файлы ресурсов, какие плагины используются, куда складывать собранный проект.

Основных тегов тут четыре:

Кратко разберем их назначение:

Тег задает имя результирующего файла сборки (jar, war, ear..), который создается в фазе package . Если параметр не задан, то используется значение по умолчанию — artifactId-version .

Тег позволяет переопределить месторасположения файлов с исходным кодом. По умолчанию файлы располагаются в директории $/src/main/java , но можно указать и любое другое место.

Тег задает директорию, куда компилятор будет сохранять результаты компиляции – *.class файлы. По умолчанию определено значение target/classes .

Тег и вложенные в нее тэги определяют местоположение файлов ресурсов. Файлы ресурсов при сборке просто копируются в директорию outputDirectory . Значение по умолчанию директории с ресурсами равно src/main/resources .

Секцию сборки можно настраивать особенно гибко. Подробнее мы рассмотрим ее немного позже.

Все, что вы хотели знать о Maven — «Java-проект от А до Я»

Всем привет, дорогие друзья. Хочу сразу извиниться: помнится, я обещал, что буду писать по статье раз в неделю. Не получилось. Просто руки не дошли до того, чтобы сесть и нормально написать, а делать так-сяк не хочу. Ныть о причинах не буду, так как мне оно не нужно, и вам уж точно не интересно. Проект не мертв, он был в стазисе 🙂 Мы продолжаем! И сегодняшний материал посвящен Мавену.

Поговорим о Мавене

Сперва его нужно установить. Разумеется так как у меня мак, показать установку я смогу только для мака. Только вот незадача. Я его давно уже установил, поэтому вам придется сделать это самостоятельно 🙂

Инструкция по установке Maven есть в этом материале.

Зачем нам Мавен

Мавен — это инструмент для сборки проекта, наряду с Gradle и Ant. Просто в силу того, что я буду использовать его в JRTB (JavaRush Telegram Bot), хочу ввести вас в курс дела. Без системы сборки сейчас не создают ни одного проекта, потому что это упрощает нашу жизнь многократно. Это позволяет:

• подтянуть все необходимые библиотеки (в терминах инструментов для сборки — зависимостей (то есть dependency));
• определить то, как именно нужно собирать проект и во что (например, хотим мы собирать в WAR или JAR или executable JAR);
• задать версию проекта в одном месте так, чтобы при сборке была указана она;
• описать проект и его жизненный цикл;
• добавлять так называется плагины (калька с английского слова Plugin);
• публиковать библиотеки в общем хранилище, чтобы другие проекты смогли подтянуть их как зависимости.

В общем, дел делает много, и все они полезные. Скажу так: для начинающих инженеров не обязательно знать весь функционал от корочки до корочки. Здесь, как и с гитом, важно понимать основу и общие понятия. Этим мы и займемся. Для нас Мавен начинается с XML файла в корне нашего проекта с именем pom.xml . Будем делать все на практике, поэтому для начала создадим наш первый проект в сообществе JavaRush Community. Чтобы сделать все по уму, я воспользуюсь шаблоном для репозитория, где уже настроены базовые вещи, которые я описывал как-то на JR. Чтобы создать, заходим в репозиторий с шаблоном и нажимаем кнопку Use this template :В результате у нас есть первый репозиторий в нашем сообществе 🙂 Стягиваем проект себе локально. Для этого через идею заходим в File -> New -> Project from Version Control . В появившемся окне вводим ссылку на проект на гитхабе (результат будет лучше, если каждый создаст отдельно у себя такой же проект и пройдет все шаги со мной): Нажимаем Clone , и ~~дело в шляпе~~ проект клонирован.

pom.xml всему голова

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

Java-университет

И ко всему прочему следующая строка тоже пишется во всех помниках (сленг такой, мол, от pom.xml :)).

А вот дальше уже интереснее: будем описывать, как мы идентифицируем проект, который описывает наш помник. На примере моей библиотеки я опишу, а потом будем добавлять это в наш помник, в новосозданный проект:

 com.github.romankh3 image-comparison 4.4.0-SNAPSHOT jar Image Comparison

• groupId — это идентификатор девелоперской организации или отдельного инженера. Обычно это домен в обратном порядке. Для примера здесь описан аккаунт romankh3 на гитхабе. Это очень важно. Скажем, у Spring экосистемы это com.springframework . Так можно отличить оригинальный проект от чьего-то ответвления или просто по совпадению имени проекта.
• artifaceId — это уже имя конкретного проекта, который описывается в этом помнике.
• version — версия этого проекта. Здесь все ясно, как божий день: добавил новый функционал, починил старый, отрефакторил или сделал какие-то еще изменения — версию увеличил.
• packaging — здесь мы описываем, как Мавен должен собирать наш проект. То ли в Jar, то ли в War, то ли еще какие-то другие.
• name — здесь уже более приятное для глаз название проекта.

 https://romankh3.github.io/image-comparison/

   The Apache Software License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0.txt

   romankh3 Roman Beskrovnyi roman.beskrovnyy@gmail.com

  git@github.com:romankh3/image-comparison.git git@github.com:romankh3/image-comparison.git https://github.com/romankh3/image-comparison

   org.mockito mockito-core 2.26.0 test  org.junit.jupiter junit-jupiter-api 5.5.2 test  com.github.romankh3 image-comparison 4.3.0 test

Здесь я добавил две библиотеки для тестирования: они всегда нужны. Как вы могли уже заметить, у зависимостей есть Scope — область применения. В нашем случае указан test , что значит, что в главном коде мы просто не увидим эту зависимость. Далее, чтобы все было по красоте, можно воспользоваться отдельным тегом для выведения версий :

  2.26.0 5.5.2 4.3.0

Так что блок депенденси можно обновить, используя конструкцию $ :

   org.mockito mockito-core $ test  org.junit.jupiter junit-jupiter-api $ test  com.github.romankh3 image-comparison $ test

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

    org.apache.maven.plugins maven-source-plugin 3.2.0  attach-sources jar

Здесь видно, что я добавил два плагина — maven-source-plugin и maven-javadoc-plugin . В каждом из плагинов есть настройки, атрибуты (параметры), которые можно задавать, тем самым настраивая плагины. Для нас в будущем это будет интересно. Пока что запомним и пойдем дальше. Таким же образом, как и для зависимостей вынесем версии плагинов в . Исходя из этого, можно создать следующий помник:

  4.0.0 com.github.javarushcommunity maven-demo 1.0-SNAPSHOT jar Maven Demo Project https://github.com/javarushcommunity/maven-demo/ 2.26.0 5.5.2 1.8 1.8 UTF-8 3.2.0   org.mockito mockito-core $ test  org.junit.jupiter junit-jupiter-api $ test     org.apache.maven.plugins maven-source-plugin $  attach-sources jar     org.apache.maven.plugins maven-javadoc-plugin $  attach-javadocs jar

Maven lifecycle

• compile — компилировать проект. Это первый этап: в ходе него можно посмотреть, нет ли ошибок компиляции в проекте. Иногда бывает разная чехарда с работой в IDEA, из-за чего появляются проблемы с компиляцией там, где их не должно быть. Так что эта команда расставит все точки над i.
• test — запускает все тесты, которые работают над JUnit и находятся там, где их ожидает Мавен ( src/test/java ваш капитан).
• package — это следующая команда, которая включает две предыдущие: то есть, внутри нее вначале запускается команда compile , потом на скомпилированный проект натравливается команда test , ну и если все ок и здесь, запускается создание архива (того архива, который мы выбираем в ))
• install — когда мы устанавливаем Мавен на машину, у нас появляется локальный гит-репозиторий, в котором хранятся библиотеки, которые мы скачиваем для проектов. Но прелесть Мавена заключается еще и в том, что мы при помощи команды install можем добавить наш проект в локальный гит-репозиторий и локально использовать наш проект как зависимость. Не верите? Попробуйте 🙂 Таким образом можно достаточно быстро посмотреть, как будет выглядеть ваш проект как зависимость у другого.
• deploy — это венец всего, что было до этого. Команда, которая дарит возможность добавлять проект не только в локальный репозиторий как install, но и на удаленный, откуда каждый человек с доступом сможет использовать его как зависимость.
• verify — команда, которая все проверит и скажет, готов ли проект к деплою.
• clean — разумеется, скомпилированные файлы и архив где-то должны храниться. Для этого у Мавена есть папка target . Это данные, которые проекту не нужны. И перед тем, как собирать проект заново, хорошо бы удалить все, что было до этого. Вот для этого и служит команда clean .

Maven Plugins

Хотел еще поговорить о плагинах, но статья и так уже вышла большая. Будет вам домашним заданием. Разберитесь, что это такое и как этим пользоваться. В продолжении статьи разберемся с Maven на практике.

Где хранятся скомпилированные maven ом файлы проекта