Try English version of Quizful



Раздаем бесплатные Q! подробности в группе Quizful.Alpha-test
Партнеры
Рекрутерам: Прескрининг кандидатов about
Топ контрибуторов
loading
loading
Знаете ли Вы, что

Лучшие IT работодатели регулярно просматривают рейтинги и профили пользователей в поисках кандидатов. Для корректного отображения ваших данных рекомендуем заполнить ваш профиль и добавить информацию о вас и вашей профессии.

Лента обновлений
ссылка 20:57:36
Комментарий от Recrut_rf:
Спасибо, сохранил функцию, может пригодится когда - ни...
ссылка 20:53:59
Добавлен вопрос в тест ASP.NET - Основы
ссылка 08:41:09
Комментарий от Krosster:
Гарний сайт для новачків. Правда деякі питання підступн...
ссылка Apr 22 22:06
Добавлен вопрос в тест SQL - Средний уровень
ссылка Apr 22 10:13
Комментарий от Entrery:
вроде выбрал ООП в сишарпе, а тут вопросы по джаве...
Статистика

Тестов: 153, вопросов: 8596. Пройдено: 402470 / 1961091.

Автоматизированные сборки в Java

head tail Статья
категория
Java
дата30.08.2012
авторYuriyDunko
голосов12

Введение

 

Сборка (англ. 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:

 

<?xml version="1.0"?>

<project name="Hello"default="compile">

    <target name="compile"

     description="compile the Java source code to class files">

        <mkdir dir="classes"/>

        <javac srcdir="."destdir="classes"/>

    </target>

    <target name="jar"depends="compile"

             description="create a Jar file for the application">

        <jar destfile="hello.jar">

            <fileset dir="classes"includes="**/*.class"/>

            <manifest>

                <attribute name="Main-Class"value="HelloProgram"/>

            </manifest>

        </jar>

    </target>

</project>

 

Здесь объявляются 2 цели(target): compile и jar. Цель jar также объявляет зависимость от цели compile, и это означает, что прежде чемAnt начнет выполнение цели jar, он должен сначала выполнить цель compile. Базовая форма описания цели выглядит следующим образом:

<targetname="D"depends="C,B,A"/>

Атрибут name уникальным образом объявляет название цели, а атрибут depends указывает, какие цели должны быть завершены перед выполнением текущей цели. Стиль исполнения build скрипта, основанный на достижении целей и разрешении их зависимостей, заметно отличается от обычного императивного стиля программирования и является, пожалуй, наиболее характерной чертой современных build инструментов.

 

Внутри каждой цели располагается список задач, которые необходимо совершить. К примеру, чтобы завершить цель compile, Antдолжен сначала создать директорию classes(задача <mkdir>) и затем вызвать javac компилятор (задача <javac>).

 

Ant выполняет каждую цель только один раз, поэтому можно не беспокоится о возможных накладных расходах, связанных с выполнением одной и той же цели несколько раз, при объявлении вложенных или рекурсивных зависимостей. При выполнении в нём есть стек выполненных операций, если операция была выполнена, то она не будет выполняться ещё раз. В отличие от make Ant максимально абстрагируется от низкоуровневых системных вызовов, к примеру, следующая команда make:

rm -rf classes/

имеет следующий аналог в Ant:

<delete dir="classes"/>

Это позволяет свободно выполнять один и тот же build как на Windows, так и на *nix подобных системах.

В базовом случае Ant используется из командной строки схожим с make образом:

$ ant target_name

Это приведет к чтению файла build.xml из текущей директории и выполнению цели target_name.

 

Maven

 

Maven (http://maven.apache.org) - это инструмент для сборки Java проекта: компиляции, создания jar, создания дистрибутива программы, генерации документации. Простые проекты можно собрать в командной строке. Если собирать большие проекты с командной строки, то команда для сборки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от зависимости от платформы и упростить написание скрипта используют инструменты для сборки проекта.

Для платформы Java существуют два основных инструмента для сборки: Ant и Maven.

Основные преимущества Maven:

Независимость от OS. Сборка проекта происходит в любой операционной системе. Файл проекта один и тот же.

- Управление зависимостями. Редко какие проекты пишутся без использования сторонних библиотек(зависимостей). Эти сторонние библиотеки зачастую тоже в свою очередь используют библиотеки разных версий. Maven позволяет управлять такими сложными зависимостями. Что позволяет разрешать конфликты версий и в случае необходимости легко переходить на новые версии библиотек.

- Возможна сборка из командной строки. Такое часто необходимо для автоматической сборки проекта на сервере (Continuous Integration).

- Хорошая интеграция со средами разработки. Основные среды разработки на java легко открывают проекты, которые собираются c помощью maven. При этом зачастую проект настраивать не нужно - он сразу готов к дальнейшей разработке. 

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

Декларативное описание проекта.

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

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

mvn archetype: generate

  -DarchetypeGroupId=org.apache.maven.archetypes

  -DgroupId=com.mycompany.app

  -DartifactId=my-app

Более подробно: http://docs.codehaus.org/display/MAVENUSER/Archetypes+List

После этого создастся файл 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">

  <modelVersion>4.0.0</modelVersion>

  <groupId>com.mycompany.app</groupId>

  <artifactId>my-app</artifactId>

  <packaging>jar</packaging>

  <version>1.0-SNAPSHOT</version>

  <name>Maven Quick Start Archetype</name>

  <url>http://maven.apache.org</url>

  <dependencies>

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>3.8.1</version>

      <scope>test</scope>

    </dependency>

  </dependencies>

</project>

pom.xml содержит модель объекта проекта (Project Object Model). POM содержит все важная информация о вашем проекте. Это очень простой POM, но содержит ключевые элементы. Рассмотрим каждый из них, чтобы ознакомить вас с POM :

-          project этот элемент верхнего уровня во всех файлов pom.xml Maven.

-          modelVersion этот элемент указывает, какую версию объектной модели этого POM использует. 

-          groupId этот элемент указывает на уникальный идентификатор организации или группы, которые создали проект. GroupId является одним из ключевых идентификаторов проекта и, как правило, основаны на полное доменное имя вашей организации. Например org.apache.maven.plugins является назначенным GroupId для всех Maven плагинов.

-          artifactId этот элемент указывает на уникальное имя базы первичных артефактов, генерируемых этим проектом. Основной артефакт для проекта, как правило, JAR-файл. Типичный артефакт производства Maven будет иметь вид <artifactId> -. <version> <extension> (Например,MyApp-1.0.jar ).

-          packaging этот элемент указывает на тип пакета, который будет использоваться этот артефакт (например, JAR, WAR, EAR и др.). Это не только означает, что если артефакт произведенного JAR, WAR, или EAR, но также может указывать на конкретного жизненного цикла для использования в качестве части процесса сборки. EAR – это если нам от какого либо проекта не нужен jar файл (к рутовый проект который содержит в себе лишь описание). В зависимости от того какой тип вы выберете, такая сборка и будет (Сборка для веб приложение отличается от настольного …).

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

-          name этот элемент указывает отображаемое имя для проекта. Это часто используется в генерации документации Maven (Это так же может быть имя проекта в Nenbeans).

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

-          description Этот элемент представляет собой общее описание вашего проекта. Это часто используется в генерации документации Maven.

Также будет создана структура проекта:

my-app

|-- pom.xml

`-- src

|-- main

|   `-- java

|       `-- com

|           `-- mycompany

|               `-- app

|                   `-- App.java

`-- test

`-- java

`-- com

`-- mycompany

`-- app

`-- AppTest.java

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

·         validate — проверяет корректность метаинформации о проекте

·         compile — компилирует исходные коды

·         test — выполняет тесты классов из предыдущего шага

·         package — упаковывает скомпилированые классы в удобно перемещаемый формат (jar или war, к примеру)

·         integration-test — отправляет упакованные классы в среду интеграционного тестирования и выполняет тесты

·         verify — проверяет корректность пакета и удовлетворение требованиям качества

·         install — переносит пакет в локальный репозиторий, откуда он (пекат) будет доступен для использования как зависимость в других проектах

·         deploy — отправляет пакет на удаленный production сервер, откуда другие разработчики его могут получить и использовать


При этом все шаги последовательны. И если, к примеру, выполнить «mvn package», то фактически будут выполнены шаги: validate, compile, test и package. Таким образом использовать Maven довольно просто. Написали код, выполнили mvn test и можно работать дальше, убедившись что код не содержит синтаксических и логических ошибок.

 

Зависимости

 

Maven конфигурируется файлом pom.xml, который может содержать блок <dependencies />. В нем описывается какие библиотеки нужны проекту для полноценного функционирования. На шаге validate Maven проверяет удовлетворены ли зависимости и если нет, то скачивает из удаленный репозиториев необходимые компоненты в репозиторий локальный. Так, если 10 проектов зависят от одной и той же библиотеки, то нам больше не надо подключать ее в 10 местах, а достаточно указать ее в файле зависимостей и она будет браться из локального репозитория Mavenа. При указании зависимостей можно указывать не только имя библиотеки, но и ее версию — таким образом, не возникнет проблем с обратной совместимостью.

 

Сейчас наш проект в зависимости от JUnit только. Для каждой внешней зависимости, вам необходимо определить, по крайней мере, 4 вещи: groupId, artifactId, version, и scope.

 

Плагины

 

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

 

К примеру, мы разрабатываем систему используя jdk 1.6, а пользователи будут использовать jdk 1.4. В этом случае нам необходимо указать итоговую версию jar-файла, и Maven включит в неё все недостающие части.

 

...

<build>

  <plugins>

    <plugin>

      <groupId>org.apache.maven.plugins</groupId>

      <artifactId>maven-compiler-plugin</artifactId>

      <version>2.0.2</version>

      <configuration>

        <source>1.6</source>

        <target>1.4</target>

      </configuration>

    </plugin>

  </plugins>

</build>

... 

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

 

Не у всех плагинов лишь одна цель и не все плагины, которые могут участвовать в сборки, необходимо описывать в том файле. К примеру, существует плагин, который создаёт настройки проекта для eclipse, чтоб его использовать его не нужно объявлять. Вызвать плагин отдельно возможно следующим образом: maven plugin:execution. «Execution» говорит какое именно из своих действий(целей) плагин должен выполнить. К примеру, вызов eclipse плагина для создания конфигурации:

mvn elipse:eclipse

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

 

Рассмотрим пример плагина который создаёт javadoc:

<plugin>

<groupId>org.codehaus.mojo</groupId>

<artifactId>build-helper-maven-plugin</artifactId>

<version>1.5</version>

<executions>

<execution>

<id>add-source</id>

<phase>generate-sources</phase>

<goals>

<goal>add-source</goal>

</goals>

<configuration>

<sources>

<source>src/main/java</source>

<source>src/main/resource</source>

</sources>

</configuration>

</execution>

</executions>

</plugin>

Если не включить секцию выполнения, то плагин ничего не будет делать, но поскольку она присутствует, мы явно координируем работу плагина (что и как делать). Поэтому, когда будет выполняться фраза сборки "add-source", данный плагин будет принимать в ней участие. В секции конфигурации мы указываем исходные параметры для работы (что-то вроде входных параметров для функции), а в секции целей (goals) мы указываем, что именно хотим, чтоб плагин сделал (у сложных плагинов может быть несколько целей). Если мы захотим вызвать данный плагин отдельно от сборки:

mvn build-helper:add-source

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

 

Хранение ресурсов в jar-файле.

 

Из-за декларативного описания Maven, можно упаковать ресурсы в JAR-файлы просто путем размещения этих ресурсов в стандартную структуру каталогов. Любые каталоги или файлы, помещенные в ${basedir}/src/main/resources каталога упакованы в JAR с точно такой же структуры, начиная с основания JAR.

my-app

|-- pom.xml

`-- src

|-- main

|   |-- java

|   |   `-- com

|   |       `-- mycompany

|   |           `-- app

|   |               `-- App.java

|   `-- resources

|       `-- META-INF

|           `-- application.properties

`-- test

`-- java

`-- com

`-- mycompany

`-- app

`-- AppTest.java

Если вы распакуете JAR, то вы увидите следующее:

|-- META-INF

| |-- MANIFEST.MF

| |-- application.properties

| `-- maven

|       `-- com.mycompany.app

|             `-- my-app

|               |-- pom.properties

|               `-- pom.xml

`-- com

`-- mycompany

`-- app

`-- App.class

 

Видимые для Maven параметры проекта.

 

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

${имя переменной}

Что значит видимые для Maven — это значит что у него есть набор своих переменных (со значением по умолчанию или без такого вообще). Для того чтоб изменить их значения, необходимо объявить такую же переменную в свойствах. Пример такой переменной, может быть кодировка исходный кодов (что может быть критично, когда команда разработчиков работает на разных платформах: Windows, Linux). Ко всем свойствам проекта можно обращаться как к переменным. Пример:

 

<properties>

        <junit.version>4.5</junit.version>

        <maven.compiler.source>1.4</maven.compiler.source>

        <maven.compiler.target>1.6</maven.compiler.target>

        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

   <dependencies>

        <dependency>

            <groupId>junit</groupId>

            <artifactId>junit</artifactId>

            <version>${junit.version}</version>

            <scope>test</scope>

        </dependency>

    </dependencies>

    <build>

        <finalName>${project.artifactId}</finalName>

            <plugin>

                <groupId>org.apache.maven.plugins</groupId>

                <artifactId>maven-compiler-plugin</artifactId>

                <version>2.3.2</version>

                <configuration>

                    <source>${maven.compiler.source}</source>

                    <target>${maven.compiler.target}</target>

                </configuration>

            </plugin>

 

Если Вам понравилась статья, проголосуйте за нее

Голосов: 12  loading...
lonely   Cr0s   Testikusik11   SamTan   gromozzzeka   Elena_P   PI_314   dimaatkaev   pomanitz   ultrasound   avsav999   P_Vyacheslav