Как из обычного idea-проекта сделать maven

Step 1) Create sample java code

Let’s start by creating a simple maven project. All this program will do is open a text file, and display the content. As a result, our program will have a file and a file, pretty simple.

To create the maven project, run the following maven command:

mvn archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-quickstart

Then you will need to enter the groupId and artifactId for your project. You can use any name here.

This will generate a project with the following layout:

Now replace the App.java with the following code:

import java.io.File;
import java.io.IOException;
import java.net.URI;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
  
    public static void main( String[] args ) throws IOException {
        URI path = new File("info.txt").toURI();
        System.out.println(Files.readAllLines(Paths.get(path), StandardCharsets.UTF_8));
  
    }
}

And create a txt file at the root directory called . Please feel free to change the file name, but if you do so, remember to change the filename at line 11, where the code is accessing the file.

info.txt

hola
hello
salut

Perfect, so we just created a piece of software. Let’s see how we can create an executable. To generate the artefact, you need to run the following maven command from your terminal (and your current directory should be the root of your project):

>> mvn clean package

After running this command, a jar will be created in the folder.And if I try to execute the jar artifact file, the output will be the following:

Martas-MBP:test-app martarey$ java -jar target/test-app-1.0-SNAPSHOT.jar 
no main manifest attribute, in target/test-app-1.0-SNAPSHOT.jar

There was an error! In the next step, we will see how you can fix this error by adding the maven jar plugin.

История

Количество артефактов в центральном репозитории Maven стремительно растет.

Maven, созданный Джейсоном ван Зилом, начинался как подпроект Apache Turbine в 2002 году. В 2003 году он был принят на голосование и признан проектом Apache Software Foundation высшего уровня

В июле 2004 года выпуск Maven стал первой важной вехой — v1.0. Версия 2.0 для Maven 2 была объявлена ​​в октябре 2005 г

после шести месяцев бета-тестирования. Maven 3.0 был выпущен в октябре 2010 года и в основном обратно совместим с Maven 2.

Информация о Maven 3.0 начала поступать в 2008 году. После восьми альфа-релизов первая бета-версия Maven 3.0 была выпущена в апреле 2010 года. В Maven 3.0 была переработана основная инфраструктура Project Builder, в результате чего файловое представление POM было отделено от его входящей информации. представление объекта памяти. Это расширило возможность надстроек Maven 3.0 использовать файлы определения проекта, не основанные на XML. Предлагаемые языки включают Ruby (уже в частном прототипе Джейсона ван Зила), YAML и Groovy .

Особое внимание было уделено обеспечению обратной совместимости Maven 3 с Maven 2. Для большинства проектов обновление до Maven 3 не потребует каких-либо корректировок их структуры проекта

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

Обновление Pom.xml

Обновление чтобы объявить как зависимости log4j, так и зависимости времени joda, для вывода в формат , убедитесь, что для упаковки установлено значение “jar”. Прочитайте комментарий ниже для пояснения.

4.0.0com.mkyong.core.utilsdateUtilsjar1.0-SNAPSHOTdateUtilshttp://maven.apache.org1.72.54.111.2.17junitjunit${junit.version}testjoda-timejoda-time${jodatime.version}log4jlog4j${log4j.version}dateutilsorg.apache.maven.pluginsmaven-eclipse-plugin2.9truefalseorg.apache.maven.pluginsmaven-compiler-plugin2.3.2${jdk.version}
					${jdk.version}org.apache.maven.pluginsmaven-jar-plugin**/log4j.propertiescom.mkyong.core.utils.App

Project model

Maven likes to give things coordinates to help locate them. Maven coordinates have three components:

• the group identifier — this is usually a DNS name in reverse order
• the artifact identifier — this is to identify artifacts within the group
• the version — this is to distinguish different versions of the same artifact.

Before we can create a project model, we need to decide what the coordinates of the artifacts produced by the project model will be.

In this case, we are creating a  file for local consumption only, so we will use the coordinates

• group id:
• artifact id:
• version:

This gives us the following project model

<project> <modelVersion>4.0.0</modelVersion> <groupId>localdomain.localhost.tutorial</groupId> <artifactId>java-archive</artifactId> <version>1.0-SNAPSHOT</version></project>

We save the project model in a file called pom.xml

Running resultant executable jar

Here’s are all steps on windows cmd. It shows directory tree before and after packaging. At the end, we are executing jar and having the same output:

D:\examples\maven-assembly-plugin-example>mvn -q clean

D:\examples\maven-assembly-plugin-example>tree /A /F
Folder PATH listing for volume Data
Volume serial number is 000000A3 68F9:EDFA
D:.
|   pom.xml
|
\---src
    \---main
        \---java
            \---com
                \---logicbig
                    \---example
                            Main.java


D:\examples\maven-assembly-plugin-example>mvn -q package

D:\examples\maven-assembly-plugin-example>tree /A /F
Folder PATH listing for volume Data
Volume serial number is 0000008D 68F9:EDFA
D:.
|   pom.xml
|
+---src
|   \---main
|       \---java
|           \---com
|               \---logicbig
|                   \---example
|                           Main.java
|
\---target
    |   maven-assembly-plugin-example-1.0-SNAPSHOT-jar-with-dependencies.jar
    |   maven-assembly-plugin-example-1.0-SNAPSHOT.jar
    |
    +---archive-tmp
    +---classes
    |   \---com
    |       \---logicbig
    |           \---example
    |                   Main.class
    |
    +---maven-archiver
    |       pom.properties
    |
    \---maven-status
        \---maven-compiler-plugin
            \---compile
                \---default-compile
                        createdFiles.lst
                        inputFiles.lst


D:\examples\maven-assembly-plugin-example>java -jar target\maven-assembly-plugin-example-1.0-SNAPSHOT-jar-with-dependencies.jar
{1=}

D:\examples\maven-assembly-plugin-example>

Create a Main class

package com.logicbig.example;


import com.google.common.collect.LinkedListMultimap;
import com.google.common.collect.Multimap;

public class Main {
    public static void main (String[] args) {
        Multimap<Integer, String> map =
                                 LinkedListMultimap.create();
        map.put(1, "apple");
        map.put(1, "banana");
        map.put(1, "orange");
        System.out.println(map);
    }
}

Run the above class to check if everything is working.

Output

 {1=}

Package the jar

Now run package goal from command line:

mvn package

It will kick off ‘assembly:single’ goal as we have attached it with ‘package’ in above pom using <execution>.

We can also run instead.

Как подключить библиотеку, которой в репозиториях нет

Подключить такую библиотеку можно несколькими способами. Например, если у вас есть свой репозиторий в локальной сети, то можно (а иногда даже нужно), положить библиотеку туда, и тем самым свести задачу к предыдущей.

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

Для обработки таких кейсов у maven тоже есть штатный механизм. Только что мы выяснили, как указать maven удалённый репозиторий, отличный от умолчального. Так вот, не обязательно использовать удалённое хранилище. Можно сделать репозиторий в локальной файловой системе, положить туда библиотеку и проинструктировать maven искать зависимости ещё и там.

Теория

Соглашение о конфигурации

Общая философия Maven заключается в стандартизации сгенерированных конструкций в соответствии с принципом Соглашения о конфигурации , чтобы использовать существующие модели в производстве программного обеспечения. Эта стратегия неизбежно сильно ограничивает вариативность, что отражено в призыве Maven придерживаться своей проектной модели. Хотя Maven подходит для новых проектов, существующие сложные проекты могут быть просто непригодны для использования Maven. Отсутствие ограничений соглашения об уровне проекта стало несколько более настраиваемым с выпуском Maven 2.

повторное использование

Maven построен вокруг идеи повторного использования, а точнее повторного использования логики сборки. Поскольку проекты обычно создаются по схожим шаблонам, логичным выбором может быть повторное использование процессов сборки. Основная идея заключается не в повторном использовании кода или функций (как в случае с Apache Ant), а просто в изменении конфигурации или написании кода. В этом основное различие между Apache Ant и Apache Maven: первый представляет собой приятную и полезную библиотеку утилит и функций, а второй представляет собой расширяемую и настраиваемую среду.

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

Жизненный цикл

Основные части жизненного цикла проекта Maven:

1. compile : создает файлы .class путем компиляции исходных кодов .java.
2. test : запускает существующие автоматические тесты JUnit, прерывая процесс, если какой-либо из них терпит неудачу.
3. package : создает файл .jar с скомпилированным .class
4. install : Скопируйте файл .jar в каталог на нашем компьютере, где maven оставляет все файлы .jar. Таким образом, эти .jars можно использовать в других проектах maven на том же компьютере.
5. deploy : копирует файл .jar на удаленный сервер, делая его доступным для любого проекта maven, имеющего доступ к этому удаленному серверу.

При выполнении любой из команд maven, например, если мы выполним mvn install , maven пройдет все фазы жизненного цикла от первой до одной команды, выполняя только те, которые не выполнялись ранее.

Есть также некоторые цели, находящиеся за пределами жизненного цикла, которые можно вызвать, но Maven предполагает, что эти цели по умолчанию не являются частью жизненного цикла (их не всегда нужно выполнять). Эти цели:

1. clean : удаляет все сгенерированные .class и .jar. После этой команды вы можете начать сборку с нуля.
2. Assembly : Создает ZIP-файл со всем необходимым для установки нашей Java-программы. Это должно быть предварительно настроено в файле xml, что должно быть включено в этот zip.
3. site : Создает веб-сайт с информацией о нашем проекте. Такая информация должна быть записана в файл pom.xml и отдельные файлы .apt.
4. site-deploy : загрузить веб-сайт на сервер, который мы настроили.
5. и т.п.

Но эти цели можно добавить в жизненный цикл с помощью объектной модели проекта (POM).

Интеграция с IDE

Maven заменяет интегрированную среду разработки (IDE), поэтому интеграция с различными IDE очень важна. Существуют плагины Maven для создания файлов конфигурации IDE из POM. В настоящее время поддерживается:

• Затмение
• NetBeans
• IntelliJ ИДЕЯ
• JDeveloper 11G (11.1.1.3)

Из каких фаз состоит жизненный цикл сборки Default (Build)?

Default (Build) — это основной жизненный цикл Maven, который используется для сборки проектов. Он включает в себя следующие фазы:

• validate — проверяет корректность метаинформации о проекте, подтверждает, является ли проект корректным и вся ли необходимая информация доступа для завершения процесса сборки.
• initialize — инициализирует состояние сборки, например, различные настройки.
• generate-sources — включает любой исходный код в фазу компиляции.
• process-sources — обрабатывает исходный код (подготавливает). Например, фильтрует определённые значения.
• generate-resources — генерирует ресурсы, которые должны быть включены в пакет.
• process-resources — копирует и отправляет ресурсы в указанную директори. Это фаза перед упаковкой.
• compile — комплирует исходный код проекта.
• process-classes — обработка файлов, полученных в результате компляции. Например, оптимизация байт-кода Java классов.
• generate-test-sources — генерирует любые тестовые ресурсы, которые должны быть включены в фазу компиляции.
• process-test-sources — обрабатывает исходный код тестов. Например, фильтрует значения.
• test-compile — компилирует исходный код тестов в указанную директорию тестов.
• process-test-classes — обрабатывает файлы, полученные в результате компиляции исходного кода тестов.
• test — запускает тесты классов, используя приемлемый фреймворк юнит-тестирования (например, Junit).
• prepare-package — выполняет все необходимые операции для подготовки пакета, непосредственно перед упаковкой.
• package — преобразует скомпилированный код и пакет в дистрибутивный формат. Такие как JAR, WAR или EAR.
• pre-integration-test — выполняет необходимые действия перед выполнением интеграционных тестов.
• integration-test — обрабатывает и распаковывает пакет, если необходимо, в среду, где будут выполняться интеграционные тесты.
• post-integration-test — выполняет действия, необходимые после выполнения интеграционных тестов. Например, освобождение ресурсов.
• verify — выполняет любые проверки для подтверждения того, что пакет пригоден и отвечает критериям качества.
• install — переносит пакет в локальный репозитарий, откуда он будет доступен для использования как зависимость в других проектах.
• deploy — копирует финальный пакет (архив) в удалённый репозитарий для, того, чтобы сделать его доступным другим разработчикам и проектам.

Здесь также необходимо уточнить два момента:

• Когда мы выполняем команду Maven, например , то будут выполнены фазы до и фаза .
• Различные задачи Maven будут привязаны к различным фазам жизненного цикла Maven в зависимости от типа архива (JAR/WAR/EAR).

Как сделать описание проекта

Но просто положить файлы в ожидаемую maven структуру директорий недостаточно. Для сборки проекта необходимо его описание в виде xml документа. Maven будет искать описание в корневой директории проекта в файле pom.xml .

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

Что тут было существенно важного и что надо запомнить? Запомнить надо вот эти три строки. Эти три строки являются идентификатором программы для внешнего мира

Программа, она же результат работы по сборке проекта, в терминологии maven называется артефактом

Эти три строки являются идентификатором программы для внешнего мира. Программа, она же результат работы по сборке проекта, в терминологии maven называется артефактом.

Непонятное слово артефакт используется здесь вместо понятного слова программа потому, что результатом работы системы сборки может быть не только собственно программа, но и библиотека или ещё что-нибудь эдакое. Комбинация параметров groupId, artifactId и version уникальна для каждого артефакта. Об уникальности этой комбинации должен позаботиться программист.

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

groupId

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

artifactId

В artifactId — строка с именем артефакта, которое придумывает его создатель. Как правило это какое-нибудь слово, иногда с разделителями в виде тире. Например hibernate-annotation-wat. artifactId должны быть уникальны в рамках groupId.

version

Ну и наконец version это версия артефакта, которую надо увеличивать при каждом более-менее значительном изменении. Версия обычно включает цифрры и буквы. Типа 1.0-SNAPSHOT

Синтаксис

Структура каталогов для проекта Java, автоматически созданная Maven

Проекты Maven настраиваются с использованием объектной модели проекта (POM) , которая хранится в файле . Пример файла выглядит так:

<project>
  <!-- model version is always 4.0.0 for Maven 2.x POMs -->
  <modelVersion>4.0.0</modelVersion>
  <!-- project coordinates, i.e. a group of values which uniquely identify this project -->
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0</version>
  <!-- library dependencies -->
  <dependencies>
    <dependency>
      <!-- coordinates of the required library -->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <!-- this dependency is only used for running and compiling tests -->
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Этот POM определяет только уникальный идентификатор проекта ( координаты ) и его зависимость от платформы JUnit . Однако этого уже достаточно для создания проекта и выполнения связанных с ним модульных тестов . Maven достигает этого, принимая идею соглашения по конфигурации , то есть Maven предоставляет значения по умолчанию для конфигурации проекта.

Структура каталогов обычного идиоматического проекта Maven имеет следующие записи каталогов:

Имя каталога	Цель
проект дома	Содержит pom.xml и все подкаталоги.
SRC / основной / Java	Содержит поставляемый исходный код Java для проекта.
SRC / основные / ресурсы	Содержит доставляемые ресурсы для проекта, например файлы свойств.
SRC / тест / Java	Содержит тестовый исходный код Java (например, тестовые примеры JUnit или TestNG) для проекта.
SRC / тест / ресурсы	Содержит ресурсы, необходимые для тестирования.

Команда скомпилирует все файлы Java, запустит все тесты и упакует поставляемый код и ресурсы (при условии, что artifactId — это my-app, а версия — 1.0).

Используя Maven, пользователь предоставляет только конфигурацию для проекта, в то время как настраиваемые плагины выполняют фактическую работу по компиляции проекта, очистке целевых каталогов, запуску модульных тестов, созданию документации API и т. Д. В общем, пользователям не нужно писать плагины самостоятельно. Сравните это с Ant и make , в котором написаны императивные процедуры для выполнения вышеупомянутых задач.

Что такое Maven? Как он работает?

Apache Maven — это Java фреймворк для автоматизации сборки проектов, компиляции, создания jar, создания дистрибутива программы, генерации документации.

Если собирать большие проекты с командной строки, то команда для сборки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от этой зависимости и упростить написание скрипта, используют инструменты для сборки проекта.

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

Setting Up the Maven Wrapper

From the project’s root directory (where is located), we run this Maven command:

If we wanted to use a particular Maven version, we can specify it like this:

This creates two files (, ) and a hidden directory (). can be used in Unix-like environments and can be used in Windows.

Along with our code, we check in the two files and the directory and its contents into our source control system like Git. Here’s how other developers can now build the code:

Instead of the usual command, they would use .

Alternatively, we can set up the wrapper by copying over the , files and directory from an existing project.

Starting from 3.7.0 version of Maven, the Wrapper will be included as a feature within core Maven itself making it even more convenient.

Плагины

Этот раздел написан не в энциклопедическом стиле . Улучшите его написание  !

Эти модули позволяют добавлять функциональные возможности . Эти плагины доступны на сайте Maven или, в противном случае, могут быть разработаны. Чтобы использовать плагин, все, что вам нужно сделать, это объявить его в POM.

Обратите внимание, что объявление наследуется по умолчанию. Объявление выполняется простым способом: groupId (если ничего не объявлено, используется значение по умолчанию org.apache.maven), artifactId и, возможно, версия (в противном случае используется последняя версия).. Пример установки artifactId в pcm-fo

Пример установки artifactId в pcm-fo

set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_38<br />
set M2_HOME=C:\dev\maven\apache-maven-3.0.4-bin\apache-maven-3.0.4<br />
set PATH=%JAVA_HOME%/bin;%M2_HOME%/bin;%PATH%<br />

pause
call mvn install:install-file -Dfile=solr-webapp-3.4.0.war -DgroupId=org.apache.solr -DartifactId=solr-webapp -Dversion=3.4.0 -Dpackaging=war
pause
call mvn install:install-file -Dfile=jodconverter-core-3.0-beta-4.jar -DgroupId=org.artofsolving.jodconverter -DartifactId=jodconverter-core -Dversion=3.0-beta-4 -Dpackaging=jar
pause
call mvn install:install-file -Dfile=parsley-flex4-2.4.1.swc -DgroupId=org.spicefactory -DartifactId=parsley-flex4 -Dversion=2.4.1 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=spicelib-util-3.0.0.swc -DgroupId=org.spicefactory -DartifactId=spicelib-util -Dversion=3.0.0 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=spicelib-reflect-3.0.0.swc -DgroupId=org.spicefactory -DartifactId=spicelib-reflect -Dversion=3.0.0 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=legacy-spicelib-utils-2.5.0.swc -DgroupId=org.spicefactory -DartifactId=legacy-spicelib-utils -Dversion=2.5.0 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=popup-1.9.swc -DgroupId=com.adobe.cairngorm -DartifactId=popup -Dversion=1.9 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=popupParsley-1.9.swc -DgroupId=com.adobe.cairngorm -DartifactId=popupParsley -Dversion=1.9 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=validation-1.13.swc -DgroupId=com.adobe.cairngorm -DartifactId=validation-1.13 -Dversion=1.13 -Dpackaging=swc
pause
call mvn install:install-file -Dfile=cairngorm-integration-0.11.swc -DgroupId=org.spicefactory -DartifactId=cairngorm-integration -Dversion=0.11 -Dpackaging=swc

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

Работа с зависимостями

4.1. Как я могу добавить зависимости в банку?

– Вы можете положить оба log4j.jar и jodatime.jar внутри final.jar, но ваши классы не могут вызывать другие классы, которые находятся внутри распаковки log4j.jar , Java jar разработан таким образом, если только вы не создадите специальный загрузчик классов, такой как плагин one-jar.

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

– Попробуйте плагин для одной банки , он создаст fat-jar, который включает все зависимости проекта в один файл jar, прочитайте эту статью – Создайте файл fat-Jar с помощью Maven

4.2 Решение Решение с одной банкой действительно хорошее, но мне не нравится пользовательский загрузчик классов и концепция жирной банки. Мое самое простое и всегда работающее решение – скопировать зависимости всего проекта в предопределенную папку и определить путь к классу зависимостей в файле манифеста jar.

Ниже приведен обновленный и окончательный , использовать для копирования всех зависимостей в плагин maven-jar/| для добавления пути к классу зависимостей.

4.0.0com.mkyong.core.utilsdateUtilsjar1.0-SNAPSHOTdateUtilshttp://maven.apache.org1.72.54.111.2.17junitjunit${junit.version}testjoda-timejoda-time${jodatime.version}log4jlog4j${log4j.version}dateutilsorg.apache.maven.pluginsmaven-eclipse-plugin2.9truefalseorg.apache.maven.pluginsmaven-compiler-plugin2.3.2${jdk.version}
					${jdk.version}org.apache.maven.pluginsmaven-jar-plugin**/log4j.propertiestruecom.mkyong.core.utils.Appdependency-jars/org.apache.maven.pluginsmaven-dependency-plugin2.5.1copy-dependenciespackagecopy-dependenciesruntime${project.build.directory}/dependency-jars/

Файл Maven pom.xml

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

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

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

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"gt;
<modelVersion>4.0.0</modelVersion>
<groupId>com.edureka.application1</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
</project>

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

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

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

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"gt;  
<modelVersion>4.0.0</modelVersion>
<groupId>com.edureka.application1</groupId>
<artifactId>my-application1</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<name>Maven Quick Start Archetype</name>
<ur>http://maven.apache.org</url>
<dependencies>
<dependency> 
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.2</version>
<scope>test</scope>
</dependency>  
</dependencies>
</project>

Описание Maven

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

1. Сборка Java проекта с подтягиванием зависимостей.
2. Создание jar.
3. Автоматически сгенерировать сопроводительную документации для кода на основе комментариев.
4. Создание дистрибутива.

Если проект java достаточно простой, можно собрать его вручную в командной строке. При больших объемах проекта такую команду записывают в bat/sh скрипт.

Структура проекта описывается через файл pom.xml (POM — Project Object Model), он должен лежать в корневой папке проекта.

Главным объектом Maven является артефакт (любая библиотека, хранящаяся в репозитории, зависимости и плагины).

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

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

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

Название артефакта состоит из названия группы, собственного названия и версии. Например, Spring в среде Maven будет иметь название:

org.springframework.spring:2.5.5.

Последний домен — artifactId, все что перед ним — groupId.

Что такое система сборки?

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

Чем она отличается от компилятора? Если коротко, то система сборки вызывает компилятор при своей работе, а компилятор о существовании системы сборки даже не подозревает.

Если более длинно, то сборка, помимо компиляции, включает в себя ещё целый спектр задач, для решения которых компилятор не пригоден от слова совсем.

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

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

Систем сборки для java по большому счёту 3 — ant, maven и gradle. ant отживает свой век, нынче его используют либо ретрограды, либо реально крутые чуваки, типа Антона Кекса, gradle пока удел хипстеров, а вот maven — стандарт индустрии. Уметь им пользоваться просто необходимо.