Artifactid 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.
Часть 4. Основы Maven
Пошаговая установка Maven
Для начала нужно установить Maven, скачав его по этой ссылке.
Далее необходимо распаковать скачанный архив и установить переменной окружения M2_HOME ссылку на местонахождение распакованного архива. Например, C:\Program Files\maven\
Чтобы проверить, что все установилось, в командной строке пропиши:
Если отобразится информация о версии Maven, Java и т.д., все готово к работе.
Теперь открой IntelliJIDEA и создай новый проект. В первом же окне выбери Maven:
Нажми Next и заполни следующее диалоговое окно:
Далее стандартно создай проект в необходимом месте.
После того, как проект создался, обрати внимание на его структуру:
Управление зависимостями в Maven
На сайте библиотеки. Если нам нужен Apache Commons IO, переходим на официальный сайт, выбираем вкладку Dependency Information. Здесь есть вся необходимая информация — ее можно просто скопировать и добавить в наш раздел dependencies.
В Maven-репозитории. В поиске введи “apache commons io”, и ты увидишь все доступные версии библиотеки. После выбора нужной, просто скопируй:
и добавь в свой pom.xml.
Виды Maven-репозиториев
Сборка Java-проекта с помощью Maven
через командную строку:
используя Intellij IDEA:
До запуска package выполняются фазы validate, compile, test. Исключение — фаза clean. Ее желательно вызывать перед каждой новой сборкой проекта. Фазы можно перечислить через пробел:
Краткое знакомство с Maven
Авторизуйтесь
Краткое знакомство с Maven
Maven — инструмент для автоматизации сборки проектов. С ним работают в основном Java-разработчики, хотя есть плагины для интеграции с C/C++, Ruby, Scala, PHP и другими языками. В статье будут рассмотрены особенности и область применения Maven, описан процесс установки и начала работы, а также разобрана структура файла описания проекта.
Назначение и особенности
Собрать на Java проект уровня «Hello, world!» можно и с помощью командной строки. Но чем сложнее разрабатываемое ПО и чем больше оно использует сторонних библиотек и ресурсов, тем сложнее будет команда для сборки. Maven разработан для облегчения этой работы.
Одна из главных особенностей фреймворка — декларативное описание проекта. Это значит, что разработчику не нужно уделять внимание каждому аспекту сборки — все необходимые параметры настроены по умолчанию. Изменения нужно вносить лишь в том объёме, в котором программист хочет отклониться от стандартных настроек.
Ещё одно достоинство проекта — гибкое управление зависимостями. Maven умеет подгружать в свой локальный репозиторий сторонние библиотеки, выбирать необходимую версию пакета, обрабатывать транзитивные зависимости.
Разработчики также подчёркивают независимость фреймворка от ОС. При работе из командной строки параметры зависят от платформы, но Maven позволяет не обращать внимания на этот аспект.
При необходимости систему сборки можно настроить под собственные нужды, используя готовые плагины и архетипы. А если ничего подходящего не нашлось — можно написать свои.
В этой статье мы будем работать с Maven с помощью командной строки, однако этот фреймворк также интегрирован в Eclipse, IntelliJ IDEA, NetBeans и другие IDE.
Установка, настройка и создание стандартного проекта
Скачать Maven можно с официальной страницы проекта. Там же вас познакомят с минимальными требованиями — на машине должен быть установлен JDK, а также потребуется свободное место на диске, около 500 мегабайт. Это место нужно не для самой установки, оно будет использовано для создания локального репозитория.
На странице скачивания вы найдёте несколько разных архивов, для первого раза лучше использовать готовые бинарники. Исходники потребуются, если захочется всё сломать покопаться в Maven.
В ОС на основе Unix переменную среды можно добавить консольной командной:
Создаём папку для нового проекта и переходим в неё. Далее создаём новый проект. Для этого в консоли выполните команду:
Выглядит довольно сложно, поэтому разберём её по порядку.
Выполнив команду, Maven сгенерирует следующую структуру проекта:
Исходники нашего проекта будут лежать в папке src/main/java (и сейчас там уже есть автоматически сгенерированный файл), но нам сейчас интереснее файл pom.xml в корневом каталоге. Это и есть тот самый файл описания проекта, на основе которого осуществляются все операции Maven. Он написан на языке POM, входящим в семейство XML:
Разберёмся, что всё это значит.
Что значат теги в pom.xml
Кстати, это хороший повод поговорить о жизненном цикле проекта. Maven выполняет сборку последовательными фазами. Приводим их названия на английском, так как они используются в качестве команд.
Поздравляем! Вы собрали проект с помощью Maven. Для более детального изучения инструмента советуем обратить внимание на эти книги и материалы.
Идеальный мавен. Часть 2: структура проекта
Это вторая статья, посвященная мавену и его использованию для организации моих проектов. Целью этой статьи будет структура проекта под управлением мавен. Особых откровений вы не найдёте, скорее набор общих правил для моих проектов. Первую статью можно прочитать здесь.
Структура проекта
Как я уже сказал, я не буду описывать здесь типовую структуру проекта на мавен – вы её знаете или легко можете найти по ссылке: Standard Directory Layout. В этой части я остановлюсь на особенностях, которые я применяю в своих проектах, итак:
Модули
Практически любой мой проект имеет несколько модулей. Практика показывает, что, когда необходимо добавить еще один модуль в проект это гораздо проще сделать в случае изначально модульного проекта. В моих проектах существует 3 типа «модулей» – POM (всегда один), несколько девелоперских модулей с кодом и BOM – если дев. модулей больше одного. В принципе POM это не модуль в понимании мавен, но я всегда оформляю его почти как «модуль» (покажу ниже). В итоге получается, что-то вроде такого:
Проектный POM
Начнём с проектного POM‘а. Я практически всегда убираю его в отдельный каталог с именем pom. Делаю я так по нескольким причинам:
Проектный POM содержит ссылку на супер POM, список модулей, версии проектов от которых он зависит (не библиотек третьих стран, а именно проектов, которые находятся параллельно в разработке в этой компании) и определение версии для модулей и проектов (dependencyManagement). Вот типичный POM для маленького проекта:
В этом примере:
версия проекта, от которого он зависит
и определение версии для модулей и проектов
Зачем это нужно? Что бы полностью исключить использование версий в девелоперских модулях. С такой конфигурацией все версии фиксируются в супер POM‘е (для внешних библиотек) и в проектных POM‘ах (для самого проекта и его зависимостей на внутренние проекты). Это не только делает POM‘ы в модулях чище, но и необходимо для того релиз процесса, который я использую.
BOM POM
Модуль с кодом
Самый примитивный POM. Включает в себя ссылку на проектный POM, artefactId, список зависимостей без версий. При необходимости секцию build c ссылками на плагины. Версия и groupId наследуются из родительского POM’а.
Пример:
Имя артефакта
groupId это имя пакета в Java для этого проекта – в последнее время это стало практически стандартом. С artifactId – немного чудесатей, для своих проектов я всегда беру имя группы плюс имя модуля, что-то вроде этого:
Почему? Имя у итогового артефакта должно быть уникальным (слишком часто все сваливают в один каталог), саму идею я вынес и мира eclipse — так там именуются плагины. Поначалу непривычно, но оно достаточно уникально, придумать его очень просто, увидев в каталоге по имени очень быстро можно найти артефакт в репозитории и source control‘е.
Следовать этой конвенции с именами не обязательно. Главное, это уникальность имени итогового артефакта.
Artifactid maven что это
Quick Overview
This is a listing of the elements directly under the POM’s project element. Notice that modelVersion contains 4.0.0. That is currently the only supported POM version, and is always required.
The Basics
Maven Coordinates
The three elements given above point to a specific version of a project, letting Maven know who we are dealing with, and when in its software lifecycle we want them.
packaging
POM Relationships
One powerful aspect of Maven is its handling of project relationships: this includes dependencies (and transitive dependencies), inheritance, and aggregation (multi-module projects).
Dependency management has a long tradition of being a complicated mess for anything but the most trivial of projects. «Jarmageddon» quickly ensues as the dependency tree becomes large and complicated. «Jar Hell» follows, where versions of dependencies on one system are not equivalent to the versions developed with, either by the wrong version given, or conflicting versions between similarly named jars.
Maven solves both problems through a common local repository from which to link projects correctly, versions and all.
Dependencies
The cornerstone of the POM is its dependency list. Most projects depend on others to build and run correctly. If all Maven does for you is manage this list, you have gained a lot. Maven downloads and links the dependencies on compilation, as well as on other goals that require them. As an added bonus, Maven brings in the dependencies of those dependencies (transitive dependencies), allowing your list to focus solely on the dependencies your project requires.
Since the dependency is described by Maven coordinates, you may be thinking: «This means that my project can only depend upon Maven artifacts!» The answer is, «Of course, but that’s a good thing.» This forces you to depend solely on dependencies that Maven can manage.
There are times, unfortunately, when a project cannot be downloaded from the central Maven repository. For example, a project may depend upon a jar that has a closed-source license which prevents it from being in a central repository. There are three methods for dealing with this scenario.
Notice that an address is still required, only this time you use the command line and the install plugin will create a POM for you with the given address.
As a motivation for this element, consider for example a project that offers an artifact targeting Java 11 but at the same time also an artifact that still supports Java 1.8. The first artifact could be equipped with the classifier jdk11 and the second one with jdk8 such that clients can choose which one to use.
Another common use case for classifiers is to attach secondary artifacts to the project’s main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files.
In the shortest terms, optional lets other projects know that, when you use this project, you do not require this dependency in order to work correctly.
Dependency Version Requirement Specification
Dependencies’ version elements define version requirements, which are used to compute dependency versions. Soft requirements can be replaced by different versions of the same artifact found elsewhere in the dependency graph. Hard requirements mandate a particular version or versions and override soft requirements. If there are no versions of a dependency that satisfy all the hard requirements for that artifact, the build fails.
Version requirements have the following syntax:
Maven picks the highest version of each project that satisfies all the hard requirements of the dependencies on that project. If no version satisfies all the hard requirements, the build fails.
Version Order Specification:
If version strings are syntactically correct Semantic Versioning 1.0.0 version numbers, then in almost all cases version comparison follows the precedence rules outlined in that specification. These versions are the commonly encountered alphanumeric ASCII strings such as 2.15.2-alpha. More precisely, this is true if both version numbers to be compared match the «valid semver» production in the BNF grammar in the semantic versioning specification. Maven does not consider any semantics implied by that specification.
Important: This is only true for Semantic Versioning 1.0.0. The Maven version order algorithm is not compatible with Semantic Versioning 2.0.0. In particular, Maven does not special case the plus sign or consider build identifiers.
Splitting and Replacing Examples:
The version order is the lexicographical order on this sequence of prefixed tokens, the shorter one padded with enough «null» values with matching prefix to have the same length as the longer one. Padded «null» values depend on the prefix of the other version: 0 for ‘.’, «» for ‘-‘. The prefixed token order is:
» alpha » beta » milestone » rc » = » cr » snapshot » final » = » ga » sp «
End Result Examples:
Note: Contrary to what was stated in some design documents, for version order, snapshots are not treated differently than releases or any other qualifier.
Version Order Testing:
The maven distribution includes a tool to check version order. It was used to produce the examples in the previous paragraphs. Feel free to run it yourself when in doubt. You can run it like this:
Exclusions
It is also sometimes useful to clip a dependency’s transitive dependencies. A dependency may have incorrectly specified scopes, or dependencies that conflict with other dependencies in your project. Using wildcard excludes makes it easy to exclude all a dependency’s transitive dependencies. In the case below you may be working with the maven-embedder and you want to manage the dependencies you use yourself, so you clip all the transitive dependencies:
Inheritance
One powerful addition that Maven brings to build management is the concept of project inheritance. Although in build systems such as Ant inheritance can be simulated, Maven makes project inheritance explicit in the project object model.
Notable elements which are not inherited include:
Notice the relativePath element. It is not required, but may be used as a signifier to Maven to first search the path given for this project’s parent, before searching the local and then remote repositories.
To see inheritance in action, just have a look at the ASF or Maven parent POM’s.