Проект maven что это
Apache Maven — основы
После публикации топика о 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 – хорошо это запомните!
На жизненном цикле останавливаться не буду, так как он хорошо описан в вышеобозначенной статье. А теперь перейдем к практике.
Установка Maven
Последнюю версию всегда можно скачать на странице загрузки на официальном сайте. Просто распаковываем архив в любую директорию. Далее необходимо создать переменную в 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, в зависимости от того, нужен ли данный репозиторий во всех проектах, либо в каком-то одном конкретном, соответственно:
Как правило на сайтах крупных проектов пишут всю информацию, необходимую для встраивания их библиотеки в проект на основе Maven, но бывают случаи, когда артефакт приходится искать очень и очень долго. Здесь нам очень сильно может помочь MVNrepository.com — он вам всегда подскажет где может находиться искомая библиотечка. Но если уж и там не нашлось, то из собственного опыта могу посоветовать гуглить « 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 — зачем?
Это общая модель проектов. В ней описываются такие общие характеристики как имя, версия, авторы и их контактная информация, VCS проекта и вообще связанные с ним сетевые ресурсы, тип проекта (например библиотека или web-модуль, в оригинальной терминологии называется packaging, хотя влияет не только на тип получаемого артефакта), связи с другими проектами, используемые при сборке плагины и описания способа их задействования. Мне кажутся особенно важными два компонента этой модели.
Связи с другими модулями
POM допускает три типа связей с другими модулями: зависимость, включение и наследование.
Зависимость, эта связь говорит, что для некоторых фаз жизненного цикла нашего модуля, требуются некоторые артефакты модулей-зависимостей (абстрактно получилось — аж самому страшно). Что конкретно и на какой фазе жизненного цикла требуется определяется так называемой областью действия зависимости. Maven понимает несколько предопределённых областей действия и позволяет добавлять свои. В качестве примера ограничусь одной областью действия: compile — она говорит, что бинарные сборки зависимости требуются на этапе компиляции, выполнения тестов и во время выполнения.
Включение — говорит, что связанный модуль является неотъемлемой частью нашего модуля. Для прохождения нашим модулем некоторой фазы жизненного цикла, входящий в него также должен пройти эту фазу. Классический пример enterprise-модуль, включающий в себя web-модуль, пакет с EJB и общую библиотеку. Очевидно, что его сборка требует сборки каждого из включаемых модулей.
Наследование. Такая связь подразумевает перенос на наследника части модели предка. Правила переноса несколько запутаны, но в основном действует принцип — значение параметра модели предка становится умолчанием для модели потомка. Пример из моей практики: был создан модуль, устанавливающий версию JDK для компиляции проектов, внутренние репозитарии для результатов, набор правил для поверки соответствия исходников стандарту кодирования, он должен был использоваться (а кое-где и действительно использовался 😉 ) как родитель для всех разрабатываемых в рамках проекта модулей.
Описание используемых при сборке плагинов
Описание состоит из имени задействуемого плагина, некоторых его настроек(они определяются плагинами индивидуально), и собственно выполняемых им целей на каждой из фаз жизненного цикла(подробное описание идей, стоящих за этими терминами см. ниже).
Этот элемент несколько чужд общей идеи POM — он несёт не декларативное описание модуля, а инструкции по его сборке конкретным инструментом.
Итоги
Репозитории артефактов
Репозитории артефактов являются выделенными хранилищами результатов сборки, устроенными так, чтобы упростить поиск нужного артефакта (по имени, версии, типу артефакта). Они позволяют группе разработчиков пользоваться результатами работы друг друга без необходимости иметь копии исходных кодов их модулей и выполнять сборку дерева зависимостей с 0. Maven-совместимые репозитарии стали стандартом де факто публикации результатов различных открытых проектов.
Нужно заметить, что pom-файлы, содержащие модель проекта, также являются артефактами и могут хранится в репозитариях вместе со всеми (на самом деле по крайней мере урезанные их версии, содержащие только идентификацию модуля и зависимости, хранятся всегда). Таким образом репозитарий является в том числе источником информации (как миннимум достаточной для дистрибуции) о хранимых в нём модулях.
Утилита управления жизненным циклом
Название получилось достаточно пафосное, однако оно вполне соответствует высокой миссии и сложности предмета.
Прежде чем погрузиться в её функции, необходимо немного познакомится с теорией организации жизненного цикла модуля в Maven. Жизненным циклом называется вся совокупность операций над модулем от инициализации сборки до развёртывания. В процессе прохождения жизненного цикла выполняются определённые операции над модулем, формируются некоторые артефакты. Жизненный цикл разделён на фазы. Каждая фаза подразумевает перевод модуля в новое состояние в результате её прохождения и появление новых артефактов. Каждая предыдущая фаза подготовливает основу для последующей. Список фаз является по сути частью POM, но глобальной, общей для всех модулей. Поный список приводить бессмысленно, но для примера приведу несколько фаз (достаточно интуитивно названных, на мой взгляд 🙂 ) в порядке их следования: compile,… test,… deploy.
В рамках каждой фазы выполняется некоторый набор целей в зависимости от модели конкретного модуля. Цель является конкретной операцией над исходными кодами и/или артефактами.
Также можно попросить выполнить отдельную задачу конкретного плагина. Например есть плагин для генерации Eclipse-проектов, задача «сгенерировать проект» которого по умолчанию не привязывается ни к одной фазе, а вызывается заинтересованными лицами вручную.
Ещё одной крайне интересной функцией mvn является создание заготовки проекта на основе архетипа. Архетип — обобщённый шаблон проекта, традиционно концентрирующийся на его структуре и используемых плагинах. Например есть стандартные архетипы java-библиотеки, web-модуля, и нестандартные, например grails приложение. Важно понимать отличие архетипа от типа проекта. Архетип — только шаблон начальной структуры и отдельных частей проекта, после создания проекта никакой информации о его архетипе не остаётся. Тип проекта — наоборот, часть модели, которая используется на протяжении всего жизненного цикла.
Что получается в сумме
Итак, мы выделили три столпа Maven. Что-же они дают нам вместе?
Заключение
Что-то я местами отклонился от центрального вопроса и вплотную занялся вопросом «как», ну да ладно…
Из всей информации, приведённой выше, можно сделать простой, но почему-то весьма редкий вывод. Maven — не утилита для сборки Java-приложений. Maven — фреймворк для автоматизации большого спектра задач при поддержке проекта. Он никак не связан с языком и платформой, более того он совершенно не обязан что-либо собирать. Вы с помощью описания моделей или написания плагинов превращаете его в тот или иной инструмент. Да, принятая в нём по модель по умолчанию — сборка Java-модулей, но это лишь умолчания…
Надеюсь, что после прочтения топика каждый может уверенно ответить на вопросы, приведённые в начале 😉
Как собрать простейшую Java программу с помощью Maven
Статья написана для тех, кто умеет писать простейшие программы на java, но не умеет их собирать. Этим людям уже известно, что такое классы, что такое пакеты и зачем нужен public static main(String[] argv), но код без среды разработки они не запускали, да и не понимают кому и зачем это вообще может понадобиться.
Сразу скажу, что Java программиста, который не может собрать свою программу из консольки, на работу не возьмут, и это в общем более чем достаточная причина, чтобы научиться искусству обращения с системами сборки. Остальное детали, которым и посвящена статья.
Я принципиально не буду обсуждать в статье ничего, кроме сборки минимального HelloWorld. Также я постараюсь опустить все технические детали, которые можно опустить и подробно раскрыть всё, без понимания чего обойтись нельзя.
Для того, чтобы воспользоваться информацией из статьи нужно знать, что такое xml, переменные окружения, зачем нужна переменная окружения PATH и как пользоваться консолью.
Зачем собирать код без IDE
Первый вопрос, который возникает у начинающего разработчика — как в реальной жизни может пригодиться умение собирать код без среды разработки. Она ведь установлена и настроена у всех — это первое, что делает программист, когда приходит на проект.
Ответ простой — для того, чтобы нормально организовать рабочий процесс — код нужно регулярно собирать, проверять что он вообще компилируется, а потом, для того чтобы убедиться в работоспособности кода, прогонять тесты.
Можно, конечно, выделить специального человека, который будет раз в 15 минут запускать IDE и проводить описанные выше процедуры, но это безумие, такие вещи следует делать автоматически.
Уметь собирать код без среды разработки — суровая необходимость. Настолько суровая, что для решения этой задачи существует особый класс программного обеспечения, называемого системами сборки.
Что такое система сборки?
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, а на выход выдаёт программу, которую уже можно запустить.
Чем она отличается от компилятора? Если коротко, то система сборки вызывает компилятор при своей работе, а компилятор о существовании системы сборки даже не подозревает.
Если более длинно, то сборка, помимо компиляции, включает в себя ещё целый спектр задач, для решения которых компилятор не пригоден от слова совсем.
Например, если программе для работы нужны какие-нибудь картинки, то положить их в директорию с программой — задача системы сборки. Если программе нужны сторонние библиотеки, то положить их в директорию с программой — задача системы сборки. Ну и так далее.
И да, если автоматическая сборка проекта настроена и работает, то нет нужды вручную конфигурировать IDE — современная среда разработки сгенерирует проект самостоятельно, достаточно показать ей где находится конфигурация для системы сборки.
Систем сборки для java по большому счёту 3 — ant, maven и gradle. ant отживает свой век, нынче его используют либо ретрограды, либо реально крутые чуваки, типа Антона Кекса, gradle пока удел хипстеров, а вот maven — стандарт индустрии. Уметь им пользоваться просто необходимо.
Как установить maven
Maven устанавливается просто копированием в нужную директорию — никакого инсталлера нет. Как и в случае с большинством консольных утилит для использования достаточно добавить директорию maven/bin в переменную окружения PATH.
То есть, если maven находится в d:/soft/maven, то в PATH надо добавить d:/soft/maven/bin
Ещё для работы maven потребует переменную JAVA_HOME, которая указывает на JDK. Если JDK находится в C:/Program Files/Java/jdk1.8.0_05, то именно такое значение нужно поместить в JAVA_HOME. Добавлять bin в конец не нужно.
После этого можно попробовать написать в консоли
Если получится, значит maven установлен.
Как структурировать проект для maven
В терминологии maven совокупность файлов с исходным кодом программы, файлов настроек и всего такого называется проектом. Директория, в которой располагаются эти файлы, называется корневой директорией проекта. В дальшейшем я буду обозначать эту директорию как
Как известно, язык программирования java навязывает программисту структуру директорий, которая диктует расположение файлов с классами. Напимер класс с полным именем com.app.HelloWorld должен находиться в файле com/app/HelloWorld.java и никак иначе.
Maven добавляет к этому ограничению ещё одно — исходный код должен находиться в директории
/src/main/java. То есть класс com.app.HelloWorld maven будет искать в
Вот как будет выглядеть этот самый HelloWorld
Как сделать описание проекта
Содержимое минимального файла pom.xml будет примерно следующим. Для прохождения туториала можно таким его и оставить, если ничего не поменять, код нормально соберётся.
Что тут было существенно важного и что надо запомнить? Запомнить надо вот эти три строки.
Эти три строки являются идентификатором программы для внешнего мира. Программа, она же результат работы по сборке проекта, в терминологии maven называется артефактом.
Непонятное слово артефакт используется здесь вместо понятного слова программа потому, что результатом работы системы сборки может быть не только собственно программа, но и библиотека или ещё что-нибудь эдакое. Комбинация параметров groupId, artifactId и version уникальна для каждого артефакта. Об уникальности этой комбинации должен позаботиться программист.
Технически, значения этих параметров могут быть любыми, но при их выборе строго рекомендуется соблюдать правила хорошего тона.
groupId
В groupId обычно находится название какого-нибудь пакета. Напомню, что название пакета согласно тем же правилам хорошего тона, должно быть именем веб-домена, владельцем которого является автор пакета, что позволяет худо-бедно обеспечить уникальность названия.
artifactId
В artifactId — строка с именем артефакта, которое придумывает его создатель. Как правило это какое-нибудь слово, иногда с разделителями в виде тире. Например hibernate-annotation-wat. artifactId должны быть уникальны в рамках groupId.
version
Ну и наконец version это версия артефакта, которую надо увеличивать при каждом более-менее значительном изменении. Версия обычно включает цифрры и буквы. Типа 1.0-SNAPSHOT
Как собрать проект
Теперь, когда структура файлов проекта соответствует ожидаемой, а его описание присутствует в файле pom.xml, для того, чтобы собрать проект, осталось только открыть консоль, сменить текущую директорию на директорию проекта и написать в консоли:
После того, как maven закончит свою работу, в директории проекта появится директория target, в которой будет находиться скомпилированный код.
Скомпилированный java код выглядит так же, как исходный, только вместо файлов с расширением java в директориях, соответствующих названиями пакетов, находятся файлы с расширением class, в которых будет уже не исходный код, а код, предназначенный для интерпретации джава-машиной.
То есть теперь этот код можно запустить.
Как запустить проект
Чтобы запустить скомпилированный код, нужно в консоли из этой же директории набрать
После того, как maven перестанет качать всякую дрянь из интернета, где-то перед здоровой табличкой с надписью BUILD SUCCESS, появится строчка Hello World.
Код отработал, всё прошло удачно.
Вот так собирают java программы с помощью системы сборки maven.
Итого
maven ищет код для сборки в директории
Инструкции по сборке maven будет искать в
Результат работы системы сборки называется артефактом.
От программиста требуется задать groupId, artifactId и version
Сборка осуществляется командой mvn compile
Скомпилированный java код выглядит так же, как исходный код, но вместо файлов с расширением java, там будут файлы с расширением class.
Введение в Maven от Balaji Varnasi и Sudha Belida (перевод)
От переводчика: Несколько лет назад я поставил себе целью быстро, но достаточно плотно познакомиться с таким повсеместно используемым фреймворком, как Apache Maven. Практически моментально мне удалось найти соответствующую литературу, но я был слегка удивлен тем фактом, что все комплексные материалы были исключительно на английском языке, на русском же была масса разрозненных статей, но полноценной книжки, которую можно было прочитать от корки до корки, мне обнаружить не удалось. Как результат, для прочтения я выбрал небольшую книжку «Introducing Maven», написанную Balaji Varnasi и Sudha Belida и выпущенную издательством Apress в 2014 году. По мере прорешивания всех задач у меня постепенно родился перевод этого издания, который хоть и пару лет пролежал у меня в столе, но возможно всё еще будет полезен сообществу.
Здесь я привожу перевод только одной из глав этой книги, а целиком её можно скачать вот по этим ссылкам на английском, или на русском языке (PDF).
Глава 6: Архетипы Maven
До этого момента вы создавали проект Maven вручную, создавая папки и файлы pom.xml с нуля. Это может быть утомительным, особенно если вам часто приходится создавать проекты. Для решения этой проблемы Maven предоставляет архетипы. Архетипы Maven — это заготовки проектов, которые позволяют пользователям легко создавать новые проекты.
Архетипы Maven также предоставляют удобную базу для обмена опытом и обеспечивают постоянство стандартной структуры директорий Maven. Например, предприятие может создать архетип с корпоративной каскадной таблицей стилей (CSS), утвержденными библиотеками JavaScript и повторно используемыми компонентами. Разработчики, используя эти архетипы для создания проектов, будут автоматически следовать стандартам компании.
Встроенные архетипы
Maven прямо «из коробки» предоставляет разработчикам сотни архетипов. Кроме того, существует множество проектов с открытым исходным кодом предоставляющих дополнительные архетипы, которые можно скачать и использовать. Maven также предоставляет архетипы плагинов с целями для создания архетипов и генерации проектов из архетипов.
У плагина архетипов существует цель generate, позволяющая просматривать и выбирать необходимый архетип. Листинг 6-1 отображает результаты запуска цели generate из командной строки. Как видите, на выбор предоставлен 491 архетип (на 2018 год их уже было более 2 тысяч – прим.перев.). Использование нескольких из них рассматривается в этой главе.
Листинг 6-1. Вызов цели generate плагина архетипов Maven
Создание Веб-проекта
Maven предоставляет архетип maven-archetype-webapp, позволяющий сгенерировать веб-приложение. Давайте создадим такое приложение путем вызова следующей команды в папке C:\apress\gswm-book\chapter6:
Эта команда выполняется в интерактивном режиме. На поступающие вопросы введите следующую информацию:
Сгенерированная структура папок должна походить на ту, что изображена на Рисунке 6-1:
Рисунок 6-1. Структура веб-проекта Maven
Файл pom.xml минимален и содержит единственную зависимость — JUnit. Maven может упростить запуск вашего веб-приложения, используя встроенные веб-серверы, такие как Tomcat или Jetty. Листинг 6-2 отображает модифицированный файл pom.xml с добавленным плагином Tomcat.
Листинг 6-2. Модифицированный файл pom.xml с внедренным плагином Tomcat
Для того, чтобы запустить это веб-приложение на сервере Tomcat вызовите следующую команду в корневой директории проекта:
Вы увидите развернутый проект и вывод, похожий на изображенный на Листинге 6-3.
Листинг 6-3. Вывод команды Tomcat run
Теперь запустите браузер и перейдите по адресу localhost:8080/gswm-web/. Вы должны увидеть веб-страницу, подобную изображенной на Рисунке 6-2.
Рисунок 6-2. Веб-проект, запущенный в браузере
Мультимодульный проект
Проекты Java Enterpise Edition (JEE) часто разделяются на несколько модулей для облегчения разработки и поддержки. Каждый из этих модулей производит такие артефакты, как Enterprise JavaBeans (EJBs), веб-сервисы, веб-проекты и клиентские JAR. Maven поддерживает разработку таких больших JEE-проектов, позволяя размещать несколько Maven-проектов внутри другого Maven-проекта. Структура такого мультимодульного проекта отображена на Рисунке 6-3. Родительский проект обладает файлом pom.xml и несколькими Maven-проектами внутри.
Рисунок 6-3. Структура мультимодульного проекта
До конца этой главы мы объясним, как построить мультимодульный проект для задачи, в которой вам нужно разделить большой проект на веб-приложение (WAR-артефакт), предоставляющее пользовательский интерфейс, сервисный проект (JAR-артефакт), содержащий код сервисного слоя, и проект постоянства (Persistence), содержащий код уровня репозитория. На Рисунке 6-4 отображено визуальное представление такого сценария.
Рисунок 6-4. Мультимодульный проект Maven
Давайте начнём процесс с создания родительского проекта. Чтобы это сделать выполните следующую команду в командной строке в папке C:\apress\gswm-book\chapter6:
Архетип pom-root создает папку gswm-parent и в ней — файл pom.xml.
Как следует из Листинга 6-4, созданный файл pom.xml имеет минимальное содержимое. Заметьте, что в теге packaging родительского проекта указан тип pom.
Листинг 6-4. Родительский файл pom.xml
Теперь создайте веб-проект запуском следующей команды в папке C:\apress\gswm-book\chapter6\gswm-parent:
В процессе генерации этого веб-проекта вы предоставили Maven такие координаты, как groupId, version и др. в виде параметров, переданные в генерирующую цель, которая и создала проект gswm-web.
Следующим шагом будет создание сервисного проекта. Находясь в папке C:\apress\gswm-book\chapter6\gswm-parent выполните следующую команду:
Обратите внимание, что вы не указывали параметр package, т.к. maven-archetype-quickstart создает JAR-проект по умолчанию. Также обратите внимание на использование параметра interactiveMode. Он просто указывает Maven выполнять команду, не запрашивая у пользователя никакой информации.
Аналогично предыдущему шагу, создайте следующий Java-проект gswm-repository путем выполнения в папке C:\apress\gswm-book\chapter6\gswm-parent следующей команды:
Теперь, когда у вас сгенерированы все проекты, взгляните на файл pom.xml в папке gswm-parent. Листинг 6-5 отображает его содержимое.
Listing 6-5. Родительской файл pom.xml с модулями
Элемент modules позволяет объявлять дочерние модули в мультимодульном проекте. По мере генерации каждого модуля Maven регистрирует их в качестве дочерних. Кроме того, он модифицирует файлы pom.xml самих модулей, добавляя в них информацию о родительском pom.xml. Листинг 6-6 отображает файл pom.xml проекта gswm-web, в котором указан родительский pom-элемент.
Listing 6-6. Файл pom.xml веб-модуля
Теперь, когда вся инфраструктура установлена, можно собрать следующий проект. Просто запустите команду mvn package находясь в папке gswm-project, как отображено в Листинге 6-7.
Listing 6-7. Команда Maven package, запущенная в директории родительского проекта
Создание архетипов
Maven предоставляет несколько способов создать новый архетип. Здесь для этого мы будем использовать уже существующий проект.
Начнем с создания прототипного проекта, который будет использоваться в качестве основы для генерации архетипа. Этот проект будет Servlet 3.0-совместимым и содержит Status Servlet, возвращающий код 200 HTTP-состояния («OK» – успешный запрос). Вместо создания веб-проекта «с нуля» скопируем ранее сгенерированный проект gswm-web и создадим gswm-web-prototype в папке C:\apress\gswm-book\chapter6. Внесите следующие изменения в только что скопированный проект:
1. Удалите все прочие ресурсы, такие как файлы, специфичные для Integrated Development Environment (IDE) (.project, .classpath и т.д.), которые вы не хотите включать в архетип.
2. Замените содержимое файла web.xml из папки webapp/WEB-INF. Это настроит веб-приложение на использование Servlet 3.0:
3. Добавьте зависимость Servlet 3.0 в файл pom.xml. Обновленное содержимое pom.xml отображено в Листинге 6-8.
Листинг 6-8. Файл pom.xml с Servlet Dependency
4. Т.к. мы будем вести разработку веб-проекта на Java, то создайте папку с именем java в директории src/main. Аналогично создайте папки test/java и test/resources в директории src.
5. Создайте файл AppStatusServlet.java, принадлежащий пакету com.apress.gswmbook.web.servlet в директории src/main/java. Пакет com.apress.gswmbook.web.servlet преобразуется в структуру папок com\apress\gswmbook\web\servlet. Исходный код файла AppStatusServelet.java отображен в Листинге 6-9.
Listing 6-9. Исходный код Java-класса AppStatusServlet
Прототипный проект по структуре будет поход на изображенный на Рис.6-5.
Рис. 6-5. Сгенерированный прототипный проект
Используя командную строку, перейдите в папку gswm-web-prototype проекта из выполните следующую команду:
По завершению команды вы увидите сообщение Archetype created in target/generated-sources/archetype. Сгенерированный архетип находится в папке gswm-web-prototype/target/generated-sources/archetype.
Следующим шагом является перенос только что сгенерированного артефакта в отдельную папку gswm-web-archetype для его настройки перед публикацией. Для этого выполните следующие шаги:
1. Создайте папку gswm-web-archetype в директории C:\apress\gswm-book\chapter6.
2. Скопируйте поддиректории и файлы из папки C:\apress\gswm-book\chapter6\gswm-web-prototype\target\generated-sources\archetype в папку gswm-web-archetype.
3. Удалите поддиректорию target из папки C:\apress\gswm-book\chapter6\gswm-web-archetype.
Структура папок для gswm-web-archetype должна быть похожа на отображенную на Рисунке 6-6.
Рис. 6-6. Структура проекта веб-архетипа
Когда проект создается из архетипа, Maven запрашивает у пользователя имя пакета. Maven создает структуру папок, соответствующую пакету, находящемуся в директории src/main/java созданного проекта. Затем Maven перемещает в этот пакет все содержимое из папки archetype-resources/src/main/java архетипа. Т.к. вы хотите, чтобы AppStatusServlet находился во вложенном пакете web.servlet, то создайте папку web/servlet и переместите AppStatusServlet туда. Новое расположение AppStatusServlet.java отображено на Рисунке 6-7.
Рис.6-7. AppStatusServlet в пакете web.servlet
Использование архетипов
Как только архетип был инсталлирован, то простейшим путем создать из него проект – это, находясь в папке C:\apress\gswm-book\chapter6, выполнить следующую команду:
В ответ на запросы Maven введите значения, указанные в Листинге 6-10, и вы увидите созданный проект.
Listing 6-10. Создание нового проекта с использованием архетипа
Т.к. файл pom.xml для test-project уже содержит плагин Tomcat, то для запуска проекта вызовите команду mvn tomcat7:run, находясь в папке C:\apress\gswmbook\chapter6\test-project. Откройте браузер и перейдите по адресу localhost:8080/test-project/status. Вы увидите надпись OK, как отображено на Рисунке 6-8.
Рис.6-8. Страница, выводимая сгенерированным проектом
Итоги
Архетипы Maven являются заготовками проектов, позволяющими быстро запускать новые проекты. В данной главе для генерации сложных Maven-проектов, таких как веб-проекты или мультимодульные проекты, использовались встроенные архетипы. Также вы познакомились с созданием и использованием пользовательских архетипов.
В следующей главе вы познакомитесь с основами генерации сайта, создания документации и отчетов при помощи Maven.