Как собрать java проект в jar

Как собрать jar

Написал небольшую програму для десктопа на TornadoFX . Не могу понять как сгенерить jar в IntellJ Idea . Пробовал стандартный способ с генерацией обычного jar -артифакта но они не запускаються( linux говорит что нет манифеста, хотя он был). Опыта с JavaFX и TornadoFX не имел ранее, поэтому прошу любой помощи.

Отслеживать
задан 8 фев 2019 в 12:01
1,360 1 1 золотой знак 9 9 серебряных знаков 21 21 бронзовый знак

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

В IntelIJ с помощью комбинации клавиш CTRL+ALT+SHIFT+S попадаем в структуру проекта. Заходим в пункт Artifacts Нажимаем на Add (зеленый плюс), выбираем JAR и пункт from modules with dependencies. В выплывающем окне выбираем главный класс. Жмем ОК, закрываем окно. Выскочит еще одно окно, в котором нажимаем Apply, закрываем это окно. Настройка закончена. Идем в пункт Build Выбираем Build Artifact, затем Build.

Исполняемый файл будет сгенерирован в директории out / Artifacts. Могут возникнуть проблемы если в проекте есть import какого-либо пакета. но этого импорта нет в classpath Если JAR не запускается, войдите в структуру проекта, пункт Modules -> Dependencies -> Add -> Project Libruary -> Attach JAR

Если вдруг Ваше приложение консольное, и Вы хотите запускать его не через консоль, нужно будет создать bat-файл в котором прописать следующую команду

java -jar filename.jar И запускать уже файл.bat.

Создание JAR-файла на Java из командной строки или IDE

Файл архива Java является инструментом архивирования, который содержит все компоненты исполняемого приложения Java. Все предопределенные библиотеки доступны в этом формате.

Чтобы включить любой из них (кроме rt.jar) в свой проект, вы должны задать путь класса для данного конкретного файла архива. Вы можете создать файл JAR в Java, используя параметры командной строки или с помощью любого IDE.

Создание Jar

Вы можете создать Jar с помощью команды, как показано ниже.

jar cf jar-file input-file(s)

Рассмотрим пример, как создать программу Java с именем Sample.java –

Sample.java

public class Sample < public static void main(String args[])< System.out.println("Hi welcome to Tutorialspoint"); >>

Если скомпилировать эту программу с помощью команды JAVAC, как показано ниже –

C:\Examples >javac Sample.java

Эта команда компилирует данный файл Java и генерирует файл .class (байт-код)

Теперь создайте файл для созданного класса, как –

C:\Sample>jar cvf sample.jar *.class added manifest adding: Sample.class(in = 434) (out= 302)(deflated 30%)

Это создаст файл для всех классов в текущем каталоге (так как мы использовали * вместо имени) с указанным именем.

Создание при помощи IDE

Вы также можете создавать архивы JAR, используя IDE. Чтобы создать файл с помощью eclipse, следуйте процедуре, приведенной ниже.

1. Откройте мастер файлов Jar. Мастер Jar File можно использовать для экспорта содержимого проекта в файл JAR. Чтобы вызвать мастер Jar File –

• В Package Explorer выберите элементы, которые вы хотите экспортировать. Если вы хотите экспортировать все классы и ресурсы в проекте, просто выберите проект.
• Нажмите на меню Файл и выберите Экспорт.
• В текстовом поле фильтра первой страницы мастера экспорта введите JAR.
• Под категорией Java выберите файл JAR.
• Нажмите на Далее.

1. Использование мастера Jar File. На странице спецификации файла JAR –

• Введите имя файла JAR и папку.
• По умолчанию экспортируются только классы. Чтобы также экспортировать исходный код, установите флажок «Экспорт исходных файлов и ресурсов Java».
• Нажмите Далее, чтобы изменить параметры упаковки JAR.
• Нажмите Next, чтобы изменить спецификацию JAR Manifest
• Нажмите на Готово.

Средняя оценка 1.9 / 5. Количество голосов: 16

Спасибо, помогите другим — напишите комментарий, добавьте информации к статье.

Или поделись статьей

Видим, что вы не нашли ответ на свой вопрос.

Помогите улучшить статью.

Напишите комментарий, что можно добавить к статье, какой информации не хватает.

Делаем свою простейшую систему сборки для Java

Довелось мне обучать одного знакомого, желающего войти в ИТ (привет, Саша!). Человек он упорный, прошел разные курсы, стажировки, упорно продолжает идти вперед и уже вполне тянет на уровень джуна. Но иногда внезапно задает такие вопросы, из которых я понимаю, что у него огромные дыры в базовых знаниях и представлениях. На курсах этому, видимо, не учат.

Один из последних вопросов был про устройство сборки. И он показал явное непонимание того, как исходный код собирается в исполняемый файл и запускается. Начинающим обычно говорят в духе «вот создаешь Gradle-проект, в IDE жмешь кнопочку запуска и все работает». Gradle/Maven при этом представляются таким черным ящиком, в котором есть кнопка сборки и запуска, а внутри — черная магия. И как только возникает необходимость что-то в этом простом процессе изменить или понять — начинаются проблемы.

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

.java и .class

Сперва небольшой ликбез.

Итак, наша Java (и прочие JVM языки такие как Kotlin) является языком с промежуточным байт-кодом.

Мы пишем исходный код на Java, сохраняем его в текстовом .java файле. Затем с помощью компилятора javac , идущего в комплекте поставки JDK, мы компилируем наш текст в байт-код в виде .class файла. Это уже бинарный файл, содержащий инструкции для виртуальной машины. Инструкции там примерно такие же, как и в любом другом машинном коде — сложить пару чисел, переместить содержимое из одной ячейки памяти в другую, вызвать указанный метод и т.п.

Полученный .class можно уже запустить с помощью специального приложения — виртуальной машины Java, JVM.

Зачем вся эта бодяга и почему бы сразу не исполнять наш код напрямую? Изначально идея была в том, чтобы единожды скомпилировав наше приложение в .class, мы потом могли запустить его на любой платформе, где есть JVM, хоть Windows, хоть Linux, хоть Java ME (помнит еще кто эту технологию?). В отличие от программ на других языках, которые сразу компилируются в нативный код, но он — разный для разных платформ, и чтобы запустить приложение на новой платформе его потребуется скомпилировать специально под нее.

То есть «другие» языки:

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

А для JVM-языков:

• Нужно иметь разные JVM, а компилятор один (в те времена JVM была простой, а компиляторы — сложными, и это было преимуществом).
• Имея скомпилированное приложение, вы можете запустить его на любой платформе, где есть JVM, от разработчика приложения вам ничего не нужно.

Вот и родился этот подход с промежуточным форматом. Но для сборки и запуска он да, представляет некоторые неудобства, ведь нужно научиться работать с двумя разными инструментами командных строки — компилятором javac и виртуальной машиной java .

Компилируем один файл

Итак, напишем простой HelloWorld:

public class HelloWorld < public static void main(String[] args) < System.out.println("Hello World"); >>

И теперь скомпилируем его вручную:

javac HelloWorld.java

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

Дальше этот .class файл мы можем запустить в JVM. Для этого нам надо вызвать JVM ( java.exe ), сказать ей где искать наши классы ( -cp . говорит искать классы в этой же папке) и какой класс надо запустить (наш HelloWorld )

java -cp . HelloWorld 

Все работает. javac скомпилировал из нашего исходного кода .class, а виртуальная машина Java запустила его и вывела результат.

Компилируем несколько файлов

Окей, один файл — это недостаточно по-джавовски. Маловато энтерпрайза и абстрактных фабрик. Давайте добавим еще два класса, делающих некую работу, и положим их в пакет print:

import print.*; public class HelloWorld < public static void main(String[] args) < IHelloWorldPrinter printer = new ConsoleHelloWorldPrinter(); printer.print("Hello World"); >> // print/IHelloWorldPrinter.java public interface IHelloWorldPrinter < public void print(String str); >// print/ConsoleHelloWorldPrinter.java public class ConsoleHelloWorldPrinter implements IHelloWorldPrinter < @Override public void print(String str) < System.out.println(str); >>

Теперь чтобы скомпилировать наше приложение надо передать javac уже три файла:

javac HelloWorld.java print/ConsoleHelloWorldPrinter.java print/IHelloWorldPrinter.java 

И JVM должна знать, где они все лежат, и ей тоже нужны все три чтобы запустить наше приложение. javac по умолчанию кладет скомпилированные .class файлы рядом с исходными .java файлами, так что нам надо указать java.exe что классы надо искать в том числе в папке ./print:

java -cp .;print HelloWorld

Добавим зависимость

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

Возьмем где-то .jar файл (не важно где, на сайте автора, например). .jar по сути это просто .zip архив с теми же самыми .class файлами. Можно его открыть любым архиватором и убедиться:

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

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

Итак, слегка модернизируем наш CosoleHelloWorldPrinter, чтобы он печатал текст каким-нибудь другим цветом:

import com.diogonunes.jcolor.*; public class ConsoleHelloWorldPrinter implements IHelloWorldPrinter < @Override public void print(String str) < System.out.println(Ansi.colorize(str, Attribute.YELLOW_TEXT(), Attribute.MAGENTA_BACK())); >>

Если мы сейчас попробуем запустить javac , то он ругнется и скажет что не знает, где ему брать классы из пакета com.diogonunes.jcolor . Чтобы он их нашел — надо ему в явном виде указать путь к .jar файлу:

javac -cp JColor-5.5.1.jar;. HelloWorld.java print/ConsoleHelloWorldPrinter.java print/IHelloWorldPrinter.java

и на этапе запуска тоже, ведь java тоже ничего не знает про то, где искать нужные библиотечные классы во время выполнения программы:

Если вместо цвета в консоли у вас выводятся спецсимволы, значит в вашей Windows по умолчанию поддержка цветной печати отключена, как ее включить описано тут

Подведем итог:

• Сперва нам необходимо превратить все .java классы нашего проекта в скомпилированные .class файлы. Для этого мы должны вызвать компилятор javac , передав ему все .java файлы и все дополнительные библиотечные классы и архивы.
• Затем мы должны запустить полученные .class файлы в JVM. Для этого надо вызвать java , передав ей пути ко всем местам где лежат наши .class, а так же имя главного класса, с которого надо начинать выполнение программы.

Наведем порядок

Хм, что-то в нашей директории стало слишком много всякого хлама. Вперемешку лежат исходные коды .java, скомпилированные файлы .class, зависимости .jar.

Давайте наведем немного порядок и разложим все по папочкам:

• В src положим исходный код
• В lib положим зависимости
• В out будем собирать наши class файлы

Дополнительно давайте положим весь исходный код в пакет helloworld . Использование классов без пакетов в Java приносит некоторые трудности. Так что переложим код в src/helloworld, и соответствующим образом изменим package и import директивы.

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

javac -d out -cp lib/JColor-5.5.1.jar;src src/helloworld/HelloWorld.java src/helloworld/print/ConsoleHelloWorldPrinter.java src/helloworld/print/IHelloWorldPrinter.java java -cp lib/JColor-5.5.1.jar;out HelloWorld

Что-то мне надоело каждый раз прописывать вручную все имена файлов. А если мы добавим еще несколько .java с исходным кодом? Нам придется опять дописывать их к командным строкам запуска javaс и java . Очень легко что-то пропустить, забыть или перепутать.

Не, мыжпрограммисты. Давайте напишем скриптик, который компилирует все классы, лежащие в src. К сожалению, javac такого из коробки не умеет и может только обрабатывать список файлов, переданный в командной строке. Ничего, сгенерируем временный список со всеми исходными файлами с помощью команды dir, положим его во временный файл build/sources.txt, а затем прочитаем его через javac . Дополнительно еще переделаем вывод, сложим классы в out/classes:

mkdir build dir /s /B .java > build/sources.txt javac -d out/classes -cp lib/;src /sources.txt

Зачем нам куча .class файлов?

А ведь .jar это удобно. Давайте сделаем сборку в него. Добавим еще строчку, собирающую содержимое нашей папки out

cd out/classes jar cf ../HelloWorld.jar .

Теперь вместо мешанины отдельных классов у нас есть один готовый файл нашего приложения, лежащий в out/HelloWorld.jar.

Автоматизируем

Заранее прошу прощения у всех линуксоидов, но напишу я скрипты свои на Windows Shell. Поскольку сейчас в моде Gradle, назовем наш скрипт microgradle.

Итак, на этапе сборки нам понадобятся все файлы лежащие в src и все .jar файлы лежащие в lib. Как было показано выше, сперва соберем исходные файлы из src в промежуточный файл, скормим его компилятору javac, получим собранные файлы в /out/classes, затем с помощью утилиты jar соберем это в архив.

На этапе запуска — возьмем все .jar файлы из out и lib и передадим их приложению java .

Добавим две команды для нашего скрипта, build для сборки и run для запуска:

@echo off if "%1"=="build" ( echo Building. mkdir build dir /s /B *.java > build/sources.txt javac -d out/classes -cp lib/*;src @build/sources.txt cd out/classes jar cf ../HelloWorld.jar . echo Build complete ) else if "%1"=="run" ( echo Running. call java -cp ./out/*;lib/* %2 ) else ( echo Unknown command: %1 )

Теперь можно выполнить microgradle build в папке с правильной структурой файлов, и наша микросборочная система все скомпилирует. А затем сделать microgradle run — и вуаля, мы получаем запущенное приложение

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

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

Конечно, про «все как у больших» я пошутил. Нашей системе не хватает еще как минимум одной очень важной вещи — управления зависимостями.

В примере выше мы просто откуда-то скачивали jar файл с библиотекой. Окей если такой файл один, вручную это сделать просто, но что если их много? Откуда их качать, где хранить?

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

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

С репозиториями, кстати, иногда бывают проблемы. Недавно компания JFrog решила прибить свой репозиторий JCenter, который был вторым по популярности. Это сломало очень много билдов различных проектов, так как многие библиотеки, особенно для Android, выкладывались только туда (процесс публикации там был проще, чем в Maven Central).

Так что никакой магии тут нет. Есть онлайн-хранилища библиотек, которые кто-то поддерживает, крупные и малые (используя различное ПО вы можете создать и свое собственное приватное хранилище для своей организации). Авторы библиотек выкладывают свои .jar файлы туда, а затем различные системы сборки ищут и скачивают эти файлы оттуда.

Реализовывать свою собственную систему управления зависимости слишком сложно, и тут мы этого делать уже не будем. Но мы можем использовать готовую, например, Apache Ivy. Эта система встроена в систему сборки Apache Ant, но может использоваться и независимо, в виде отдельного консольного приложения.

Напишем файл ivy.xml с конфигурацией и положим в корень нашего проекта. Опишем тут, что для работы нашего проекта нам нужна библиотека JColor версии 5.5.1:

Положим в корень нашего проекта исполняемый архив Ivy (взять его можно с официального сайта) и допишем таск dependencies в наш скрипт microgradle

@echo off if "%1"=="build" ( echo Building. mkdir build dir /s /B *.java > build/sources.txt javac -d out/classes -cp lib/*;src @build/sources.txt cd out/classes jar cf ../HelloWorld.jar . echo Build complete ) else if "%1"=="run" ( echo Running. call java -cp ./out/*;lib/* %2 ) else if "%1"=="dependencies" ( echo Resolving dependencies. mkdir lib java -jar ./ivy-2.5.2.jar -retrieve "lib/[artifact]-[type]-[revision].[ext] ) else ( echo Unknown command: %1 )

Вуаля, теперь нам не нужно хранить нашу зависимость вручную в папке lib. Все что надо — прописать в нашем файлике, затем сделать шаг microgradle dependencies . Он запустит под капотом Ivy, который прочитает наш ivy.xml и скачает с репозитория Maven Central все что там написано в папку lib.

После этого шаг build уже подхватит эти скачанные .jar файлы и все соберет как надо.

Что дальше

Дальше можно придумывать много чего. Например, полноценные системы сборки не перекомпилируют файлы, если в них нет изменений, в отличие от нашей. А на проектах с сотнями файлов это важно. Полноценные системы имеют локальный кеш зависимостей, имеют конфигурируемые настройки, плагины, возможность создавать собственные шаги сборки и много-много чего еще.

Но наша микросистема уже имеет все основные черты настоящей системы сборки:

• Имеет структуру папок и файлов с описанием проекта
• Умеет скачивать зависимости
• Умеет компилировать проект
• Умеет запускать

Вполне достаточно для сборки маленького проекта.

Заключение

Этим туториалом я попытался показать, как вообще эти системы работают, а главное — зачем они нужны. Мы по шагам прошли от ручной компиляции отдельных файлов, которая с каждым шагом становилась все более сложной и громоздкой, к автоматической системе. Умеющей управлять зависимостями, автоматически подхватывать новые файлы, собирать и запускать наше приложение. Повторив тем самым в миниатюре эволюцию реальных систем.

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

Исходный код проекта можно найти в репозитории.

• java
• система сборки
• сезон java one love
• туториал

Сборка Java-проекта с использованием Maven

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

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

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

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

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

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

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

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

• Загрузите и распакуйте архив с кодом этого урока, либо кнонируйте из репозитория с помощью Git: git clone https://github.com/spring-guides/gs-maven.git
• Перейдите в каталог gs-maven/initial
• Забегая вперед, установите Maven

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

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

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

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

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

+-- src +-- main +-- java +-- hello

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

package hello; public class HelloWorld < public static void main(String[] args) < Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>

package hello; public class Greeter < public String sayHello() < return "Hello world!"; >>

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

Maven можно получить, скачав zip-файл с maven.apache.org/download.cgi. Необходимы только бинарные файлы, так что ищите ссылку на архив с именем apache-maven-version-bin.zip или apache-maven-version-bin.tar.gz.

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

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

mvn -v

Если всё было сделано правильно, то вы увидите сообщение примерно такого содержания:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 07:51:28-0600) Maven home: /usr/share/maven Java version: 1.7.0_09, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"

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

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

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

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

 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
4.0.0 
org.springframework 
gs-maven 
jar 
0.1.0
 
 
 
 
org.apache.maven.plugins 
maven-shade-plugin 
2.1 
 
 
package 
 
shade 
 
 
 
 implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> 
hello.HelloWorld 
 
 
 
 
 
 
 

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

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

Когда речь заходит о выборе схемы управления версиями, Spring рекомендует [семантическое управление версиями] semver.org подход.

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

Сборка Java кода

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

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

mvn compile

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

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

mvn 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 :

mvn install

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

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

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

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

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

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

package hello; import org.joda.time.LocalTime; public class HelloWorld < public static void main(String[] args) < LocalTime currentTime = new LocalTime(); System.out.println("The current local time is: " + currentTime); Greeter greeter = new Greeter(); System.out.println(greeter.sayHello()); >>

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

Если бы вы запустили mvn compile для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке. Вы можете это исправить, добавив следующие строки в pom.xml(в пределах элемента):

 
 
joda-time 
joda-time 
2.2 

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

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

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

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

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

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

 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
4.0.0 
org.springframework 
gs-maven 
jar 
0.1.0
 
 
 
 
joda-time 
joda-time 
2.2 
 
 

 
 
 
 
org.apache.maven.plugins 
maven-shade-plugin 
2.1 
 
 
package 
 
shade 
 
 
 
 implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> 
hello.HelloWorld 
 
 
 
 
 
 
 

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

Итог

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

С оригинальным текстом урока вы можете ознакомиться на spring.io.