Что значит собрать проект java
Сборка Java-проекта с использованием Maven
Этот урок освещает создание вами простого Java-приложения с использованием Maven.
Что вы создадите
Вы создадите простое приложение и соберете его с помощью Maven.
Что вам потребуется
Как проходить этот урок
Как и большинство уроков по Spring, вы можете начать с нуля и выполнять каждый шаг, либо пропустить базовые шаги, которые вам уже знакомы. В любом случае, вы в конечном итоге получите рабочий код.
Чтобы начать с нуля, перейдите в Настройка проекта.
Настройка проекта
Для начала вам необходимо настроить Java-проект перед тем, как собрать его Maven’ом. Т.к. урок посвящен Maven, сделаем проект максимально простым, насколько это возможно.
Создание структуры каталогов
Теперь, когда у вас есть проект, который вы можете собрать с Maven, вам нужно установит сам Maven.
Maven можно получить, скачав zip-файл с maven.apache.org/download.cgi. Необходимы только бинарные файлы, так что ищите ссылку на архив с именем apache-maven-version-bin.zip или apache-maven-version-bin.tar.gz.
Распакуйте архив и добавьте путь к каталогу bin в переменную окружения path.
Чтобы протестировать правильность установки Maven, запустите в командной строке:
Если всё было сделано правильно, то вы увидите сообщение примерно такого содержания:
Теперь у вас есть установленный Maven.
Создание простой сборки Maven
Теперь, когда Maven установлен, вам необходимо создать определение Maven-проекта. Maven-проекты определяются как XML-файлы с названием pom.xml. Помимо всего прочего, этот файл определяет имя проекта, версию, а также зависимости от сторонних библиотек.
Создайте файл с названием pom.xml в корневом каталоге проекта и наполните его следующим содержанием:
За исключением дополнительного элемента
, это простейший из pom.xml файлов, необходимый для сборки Java проекта. Он включает следующие детали конфигурации проекта:
На данном этапе мы имеем минимальное, но уже рабочее определение Maven-проекта.
Сборка Java кода
Теперь все готово для сборки проекта Maven’ом. Вы можете выполнить несколько этапов жизненного цикла сборки, включая компиляцию кода, создание библиотеки пакета(такого, как JAR-файл) и установку библиотеки в локальный репозиторий Maven зависимостей.
Попробуйте собрать, выполнив команду, приведенную ниже:
Этим вы запустите Maven, передав ему указание на выполнение задачи compile. Когда он закончит, вы должны найни скомпилированные .class файлы в target/classes директории.
Вряд ли вы захотите распостранять или работать напрямую с .class файлами, поэтому вам полее подойдет выполнение задачи package:
с «jar» на «war», то результатом будет WAR-файл в target директории вместо JAR-файла.
Maven также хранит репозиторий зависимостей на вашей локальной машине(обычно в .m2/repository директории в вашей домашней папке) для быстрого доступа к зависимостям проекта. Если вы хотите добавить JAR-файл вашего проекта в локальный репозиторий, тогда вам необходимо выполнить задачу install :
Задача install включает компиляцию, тестирование, упаковку кода проекта, а затем копирование в локальный репозиторий, тем самым другие проекты смогут ссылаться на него как на зависимость.
Говоря о зависимостях, пришло время объявлять зависимости в Maven сборке.
Объявление зависимостей
Простой «Hello World» пример полностью автономный и не зависит от каких-либо дополнительных библиотек. Однако, большинство приложений зависит от внешних библиотек, с реализацией распостраненного и/или сложного функционала.
К примеру, предположим, что в дополнение к «Hello World!» вы хотите, чтобы приложение печатало текущую дату и время. Вы могли бы использовать функциональность из стандартных(native) Java библиотек, но мы можем сделать это и другими интересными способами, например с помощью Joda Time библиотеки.
Здесь HelloWorld использует Joda Time LocalTime класс для получения и печати текущего времени.
Если бы вы запустили mvn compile для сборки проекта сейчас, то получили бы ошибку сборки, потому что вы не объявили Joda Time компилируемую зависимость в сборке. Вы можете это исправить, добавив следующие строки в pom.xml(в пределах
Этот блок XML объявляет список зависимостей проекта. В частности, он объявляет единственную зависимость от Joda Time библиотеки. В элементе, зависимость определяется через описание трех вложенных элементов:
По умолчанию, все зависимости определены как зависимости. Т.е. они должны быть доступны во время компиляции(а если вы собираете WAR-файл, то в /WEB-INF/lib каталоге). Кроме того, вы можете добавить элемент, с одним из значений:
Здесь полная версия pom.xml :
Поздравляем! Вы создали простой, но эффективный файл сборки Maven для сборки Java проектов.
Сборка Java приложений при помощи Apache Ant, quick start
О чем эта статья
Одной из отличительных особенностей платформы Java является ее независимость от используемого инструментария. Вы можете разрабатывать сколь угодно большое Java приложение при помощи блокнота (vi) и командной строки. Понятно что так никто не делает и все используют какую-то IDE. Как следствие независимости от инструментов — IDE для Java много. Все это хорошо но есть одна особенность. Если Ваш коллега делал приложение и для сборки проекта использовал IDE_A то в IDE_B которая стоит у Вас — собрать приложение не получится.
В общем-то это давно уже не проблема. Хорошей практикой считается использовать систему сборки не зависящую от IDE. Для Java их две это Apache-Ant и Maven (тоже в общем-то Apache). Но тут есть один подводный камень. Если в Delphi или Visual Studio, чтобы создать и собрать приложение надо кликнуть в кнопку new пройтись по шагам визарда и нажать кнопку собрать, то написание ant скрипта для сборки например web приложения, особенно для начинающего разработчика, задача не тривиальная.
В статье рассматривается сборка и деплой Java web приложения шаг за шагом.
В целом задачу можно решить как с помощью ant так и с помощью maven, здесь будет рассмотрен ant. Для начинающих он проще и нагляднее.
Примечание 10 лет спустя
Решил посмотрел на свою статью написанную 10 лет назад. Звучит старомодно, в 2021 я в общем случае не рекомендую собирать Java приложения при помощи ant. НО если уж у вас возникла такая необходимость, то статья все еще может помочь. Пусть живет.
Зачем нужен скрипт сборки
Собираем и деплоим war
Есть много способов собрать war и есть много способов расположить файлы приложения. В статье дается один способ — может быть не самый лучший но вполне неплохой.
Структура проекта
Файлы проекта располагаем вот так.
В реальном проекте вместо stepN.xml будет build.xml. Библиотек будет больше и каждую следует располагать в отдельном каталоге. Имена пакетов выдают что я работаю в компании DataArt.
Шаг 1: компиляция
Шаг 2: улучшаем скрипт
Скрипт шага 1 довольно не гибкий и ряд путей там прописан дав раза. Давайте его улучшим
Шаг 3: Пути к библиотекам
Пути к библиотекам прописаны жестко в середине кода. Это не есть хорошо, меняем.
Шаг 4: Управление кофигурациями
Управление конфигурациями это мега технология о которой меня рассказал матерый американский программер Walden Mathews. Суть в следующем, при сборке вы пишете в файл свойств таймаут или путь до какого-то внешнего каталога или URL какого-то сервиса. На вашей локальной машине он один, на боевом сервере (или на машине коллеги другой). Вопрос — как использовать правильные значения свойств и не поубивать друг друга.
Здесь в target init читается файл с именем, совпадающим с Вашим именем пользователя. Если такой не находится сборка дальше не идет. А уже потом читаются дефолтные свойства из default. Так как в ant значения свойств переопределять нельзя то в default должны быть все свойства, а в Вашем файле только те значения которых отличаются.
default.properties
semenych.properties
Обратите внимание что в команде написано просто mihalych а не mihalych.properties
Шаг 5: Давайте уже соберем jar и war файл
Да действительно давайте.
вот эта секция делает замену внутри web.xml при этом web.xml выглядит так:
Шаг 6: war готов, последний штрих, деплой
Скрипт будет делать так называемый «холодный» деплой т.е. развертывание приложения с остановкой сервера. В ряде случаев «холодный» деплой позволяет избежать ряда проблем связанных с освобождением ресурсов и чисткой кэша.
Заключение
Вот собственно и все. Это почти готовый пример взятый из реального проекта. Пользуйтесь на здоровье, не забывайте писать комментарии.
Автоматизированные сборки в Java
Введение
Сборка (англ. assembly) — двоичный файл, содержащий исполняемый код программы или (реже) другой подготовленный для использования информационный продукт.
Автоматизация сборки — этап написания скриптов или автоматизация широкого спектра задач применительно к ПО, применяемому разработчиками в их повседневной деятельности, включая такие действия, как:
1. компиляция исходного кода в бинарный код
2. сборка бинарного кода
3. выполнение тестов
4. разворачивание программы на производственной платформе
5. написание сопроводительной документации или описание изменений новой версии
Автоматизированные сборки jar файлов.
Чтобы автоматизировать данные процессы и уменьшить участие программиста в сборке были созданы автоматизированные сборщики java-программ (На подобии уже существующих альтернатив в других языках).
Ant the Java build tool
Ant (http://ant.apache.org/) стал логическим продолжением make, схожий по принципу работы инструмент, основной задачей которого была обеспечить автоматизацию и мульти платформенность процесса сборки Java приложений.
В отличие от make, в Ant используется несколько иной подход к описанию целей и зависимостей между ними. В Ant понятие цели не привязано к некоторому файлу, и является описанием некоторого действия. Также отличается формат Make файлов, Ant использует XML разметку вместо простого текста и не требует обязательного использования символа табуляции для выделения команд, в случае make.
Приведем пример build.xml:
name = «Hello» default = «compile» >
description = «compile the Java source code to class files» >
srcdir = «.» destdir = «classes» />
name = «jar» depends = «compile»
description = «create a Jar file for the application» >
dir = «classes» includes = «**/*.class» />
Здесь объявляются 2 цели(target): compile и jar. Цель jar также объявляет зависимость от цели compile, и это означает, что прежде чемAnt начнет выполнение цели jar, он должен сначала выполнить цель compile. Базовая форма описания цели выглядит следующим образом:
name = «D» depends = «C,B,A» />
Атрибут name уникальным образом объявляет название цели, а атрибут depends указывает, какие цели должны быть завершены перед выполнением текущей цели. Стиль исполнения build скрипта, основанный на достижении целей и разрешении их зависимостей, заметно отличается от обычного императивного стиля программирования и является, пожалуй, наиболее характерной чертой современных build инструментов.
Внутри каждой цели располагается список задач, которые необходимо совершить. К примеру, чтобы завершить цель compile, Antдолжен сначала создать директорию classes(задача ) и затем вызвать javac компилятор (задача ).
Ant выполняет каждую цель только один раз, поэтому можно не беспокоится о возможных накладных расходах, связанных с выполнением одной и той же цели несколько раз, при объявлении вложенных или рекурсивных зависимостей. При выполнении в нём есть стек выполненных операций, если операция была выполнена, то она не будет выполняться ещё раз. В отличие от make Ant максимально абстрагируется от низкоуровневых системных вызовов, к примеру, следующая команда make:
имеет следующий аналог в Ant:
Это позволяет свободно выполнять один и тот же build как на Windows, так и на *nix подобных системах.
В базовом случае Ant используется из командной строки схожим с make образом:
$ ant target_name
Это приведет к чтению файла build.xml из текущей директории и выполнению цели target_name.
Maven
Для платформы Java существуют два основных инструмента для сборки: Ant и Maven.
Основные преимущества Maven:
Независимость от OS. Сборка проекта происходит в любой операционной системе. Файл проекта один и тот же.
Декларативное описание проекта.
Maven может обеспечить выгоды для процесса сборки, используя стандартные правила и практику, чтобы ускорить цикл разработки, в то же время, помогая вам достичь более высокий уровень успеха.
В основе проекта Maven, как и в анте, лежит xml описание проекта, но для Mavenа мы можем сгенерировать описание из архетипа. Архетип определяется как оригинальный образец или модель, из которой все другие вещи того же рода делаются. В Maven архетип, шаблон проекта, который в сочетании с некоторым вводом данных пользователем получаем рабочий Maven проект.
mvn archetype: generate
Maven Quick Start Archetype
pom.xml содержит модель объекта проекта (Project Object Model). POM содержит все важная информация о вашем проекте. Это очень простой POM, но содержит ключевые элементы. Рассмотрим каждый из них, чтобы ознакомить вас с POM :
— project этот элемент верхнего уровня во всех файлов pom.xml Maven.
— modelVersion этот элемент указывает, какую версию объектной модели этого POM использует.
— groupId этот элемент указывает на уникальный идентификатор организации или группы, которые создали проект. GroupId является одним из ключевых идентификаторов проекта и, как правило, основаны на полное доменное имя вашей организации. Например org.apache.maven.plugins является назначенным GroupId для всех Maven плагинов.
— packaging этот элемент указывает на тип пакета, который будет использоваться этот артефакт (например, JAR, WAR, EAR и др.). Это не только означает, что если артефакт произведенного JAR, WAR, или EAR, но также может указывать на конкретного жизненного цикла для использования в качестве части процесса сборки. EAR – это если нам от какого либо проекта не нужен jar файл (к рутовый проект который содержит в себе лишь описание). В зависимости от того какой тип вы выберете, такая сборка и будет (Сборка для веб приложение отличается от настольного …).
— version этот элемент указывает на версию артефакта, генерируемых проектом. Maven проходит долгий путь, чтобы помочь вам в управление версиями, и вы часто будете видеть SNAPSHOT обозначение в версии, которая указывает, что проект находится в состоянии развития.
— name этот элемент указывает отображаемое имя для проекта. Это часто используется в генерации документации Maven (Это так же может быть имя проекта в Nenbeans).
— url этот элемент указывает, где можно найти сайте проекта. Это часто используется в генерации документации Maven.
— description Этот элемент представляет собой общее описание вашего проекта. Это часто используется в генерации документации Maven.
Также будет создана структура проекта:
Одно из основных отличий Maven в том что цели жизненного цикла сборки уже определены, вы только можете вызывать определённую цели или же настраивать её под свои нужды. Вот список целей:
· validate — проверяет корректность метаинформации о проекте
· compile — компилирует исходные коды
· test — выполняет тесты классов из предыдущего шага
· package — упаковывает скомпилированые классы в удобно перемещаемый формат (jar или war, к примеру)
· integration-test — отправляет упакованные классы в среду интеграционного тестирования и выполняет тесты
· verify — проверяет корректность пакета и удовлетворение требованиям качества
· install — переносит пакет в локальный репозиторий, откуда он (пекат) будет доступен для использования как зависимость в других проектах
· deploy — отправляет пакет на удаленный production сервер, откуда другие разработчики его могут получить и использовать
При этом все шаги последовательны. И если, к примеру, выполнить «mvn package», то фактически будут выполнены шаги: validate, compile, test и package. Таким образом использовать Maven довольно просто. Написали код, выполнили mvn test и можно работать дальше, убедившись что код не содержит синтаксических и логических ошибок.
Зависимости
Сейчас наш проект в зависимости от JUnit только. Для каждой внешней зависимости, вам необходимо определить, по крайней мере, 4 вещи: groupId, artifactId, version, и scope.
Плагины
Всякий раз, когда вы хотите настроить построить для проекта Maven, это делается путем добавления или перенастройки плагинов.
К примеру, мы разрабатываем систему используя jdk 1.6, а пользователи будут использовать jdk 1.4. В этом случае нам необходимо указать итоговую версию jar-файла, и Maven включит в неё все недостающие части.
Как собрать простейшую 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.