Миграция в Maven 2 (часть 1)

Каждый Jar в репозитории Maven 2, указанный в POM как зависимость, имеет groupId, artifactId и номер версии. Эти три части зависимости вместе составляют так называемую координату — groupId: artifactId: version. Необязательной частью координаты может быть классификатор , который вы используете для вторичных артефактов, таких как jar-файлы исходного кода или javadoc. GroupId сообщает Maven, какому проекту принадлежит Jar-файл, а artifactId и версия вместе сообщают Maven, какой Jar-файл вы хотите использовать. Например, если мы хотим использовать разные Jar-файлы из проекта Spring Framework, мы указываем <groupId> spring </ groupId> и <version> 2.0.2 </ version> для них обоих, но <artifactId> spring-core < / artifactId> для основного Spring Jar и <artifactId> spring-beans </ artifactId>для весенних бобовых

Процессы сборки Maven известны как жизненные циклы . Существует три различных жизненных цикла: создание, создание и очистка. Жизненный цикл сборки состоит из 22 фаз, сайта — четырех фаз, а очистки — трех фаз. Жизненный цикл сборки — это тот, который вы обычно хотите использовать, так как он включает в себя фазы компиляции и тестирования, а также многие другие. Жизненный цикл сайта — это тот, который вы будете использовать для создания веб-сайта проекта. Чистый жизненный цикл удалит файлы классов и веб-сайт, сгенерированные жизненными циклами сборки и сайта. В Maven также есть средство для создания целей, которые могут быть выполнены пользователями для различных плагинов Maven. Эти цели также могут быть связаны с различными фазами жизненного цикла в жизненных циклах сборки Maven, чтобы облегчить использование плагинов.

Проекты, использующие Maven в качестве инструмента сборки, обычно следуют соглашениям Maven. Исходные файлы в проектах Maven обычно находятся в проектах / src / main / language и project / src / test / language , но могут находиться в других каталогах, указанных в POM. файл. Это также облегчает работу начинающих разработчиков, поскольку они будут знать, где искать различные исходные файлы в проекте.

По мере роста вашего проекта, когда вы обнаружите, что хотите разместить разные куски вашей сборки в разных Jar-файлах, вы захотите использовать возможности сборки Maven Reactor и munti-module. Эта особенность Maven будет подробно рассматривается в главе 6 и главе 7 из Maven: The Definitive Guide , а также будет рассмотрена в части 2 этой серии.

Maven также прекрасно интегрируется с несколькими различными системами непрерывной интеграции, как с открытым исходным кодом, так и с коммерческими. Круиз-контроль может запускать вашу сборку в определенные периоды , Continuum был создан с нуля как часть экосистемы Maven, и Hudson также имеет хорошую интеграцию с Maven 2 . TeamCity от JetBrains и Bamboo от Atlassian поддерживают Maven 2 из коробки и предоставляют полезную статистику о вашей сборке. Вы можете найти инструкции по настройке сборки Maven здесь для TeamCity и здесь для Bamboo.

Mavenize My Build!

Теперь самое интересное! Для начала загрузите Maven 2 (2.0.9 на момент написания этой статьи) и следуйте инструкциям по установке . После установки Maven 2 загрузите исходный код Guice 1.0 и разархивируйте исходный код в своем собственном каталоге. Guice — это небольшой, но нетривиальный проект реального мира, который может в полной мере воспользоваться мультимодульными возможностями Maven. Наша цель — создать эквивалентные артефакты в качестве текущих сценариев сборки ANT от Guice, одновременно сводя к минимуму рефакторинг кодовой базы. Примечание. Я использую Java 6 в качестве JDK. Если вы используете Java 5, вам может потребоваться установить javax.activation Jar в локальный репозиторий. Инструкции для этого могут быть на Coping wth Sun JARстр. Кувшин активации и другие файлы из этой категории можно найти в загрузках Spring Framework в его spring-framework-xxx-with-dependencies.zip

Eclipse , IntelliJ и NetBeans имеют плагины для редактора POM Maven 2, которые могут помочь синхронизировать ваш проект POM и IDE, а также найти имя Jar, которое вы ищете в Ibiblio. m2eclipse — самый зрелый плагин для Eclipse, и он очень полезен для вас. Maven Reloaded полезен для пользователей IntelliJ 6 (эта функциональность встроена в V7) и Maven Repo Searchочень полезен для поиска зависимости, которую вы ищете с IntelliJ. Кроме того, Maven 2 может также генерировать дескрипторы проектов для каждой из этих IDE с помощью простой команды, что делает нейтральную среду разработки IDE реальностью. Тем не менее, файлы POM и сборки Maven 2 почти так же легко работать с помощью текстового редактора и командной строки, если вы не являетесь поклонником IDE. Поскольку Guice — это проект IntelliJ, возможно, проще всего воспользоваться этой опцией, если вы не используете IntelliJ.

Указание каталогов исходного и тестового кода

Разархивировав исходный каталог Guice, вы обнаружите, что файл pom.xml создан, но в нем мало что есть. Однако то, что он имеет, безусловно, полезно, и мы можем использовать его для начала Плагин компилятора определяет версию Java, которую мы хотим использовать, но нам нужно будет указать исходные и тестовые исходные каталоги. Давайте добавим их. Ваш раздел сборки теперь должен выглядеть

  <build>
    <sourceDirectory>src</sourceDirectory>
    <testSourceDirectory>test</testSourceDirectory>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
  </build>

Если у вас есть несколько исходных или тестовых каталогов, плагин builder-helper абсолютно бесценен.

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

Указание и установка зависимостей Guice

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

  <dependencies>
    <dependency>
      <groupId>aopalliance</groupId>
      <artifactId>aopalliance</artifactId>
      <version>1.0</version>
    </dependency>
    <dependency>
      <groupId>cglib</groupId>
      <artifactId>cglib-nodep</artifactId>
      <version>2.2-beta-1</version>
    </dependency>
    <dependency>
      <groupId>asm</groupId>
      <artifactId>asm</artifactId>
      <version>3.0</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

но пока не компилируйте источник. Версия cgli-nodep, необходимая Guice, пока отсутствует в репозитории Maven Central, поэтому нам нужно установить ее самостоятельно. Перейдите в каталог guice-1.0-src / lib / build в командной строке и введите

mvn install:install-file -Dfile=cglib-nodep-2.2_beta1.jar -DgroupId=cglib -DartifactId=cglib-nodep -Dversion=2.2-beta-1 -Dpackaging=jar

Это установит cglib-nodep-2.2_beta1.jar, используя соответствующие соглашения по именованию Maven для бета-файлов. Вернитесь в корневой каталог проекта в командной строке и введите

> mvn compile

и вы должны увидеть СТРОИТЬ УСПЕШНОЕ . Хотя нам не нужен JUnit для выполнения компиляции, он понадобится через минуту, поэтому мы оставим его там.

Краткое примечание о переходных зависимостях и близости

Если бы мы использовали выпущенную версию cgib, которая была размещена на Ibiblio, нам не нужно было бы перечислять зависимость ASM, потому что cglib уже имеет зависимость от ASM 1.5.3. Однако, если выйдет более новая версия ASM, которую мы хотели бы использовать вместо этого (как в этом случае), мы можем указать эту версию в нашем POM, и она будет использоваться во время компиляции вместо версии, уже используемой cglib. Путь к классам компиляции в Maven 2 использует jar-файлы, перечисленные в разделе <dependency>, и все jar-файлы, от которых зависят эти jar-файлы.

Это происходит из-за алгоритма, часто называемого алгоритмом близости, потому что Maven определяет версию Jar для использования на основе версии, «ближайшей» к зависимостям, перечисленным в вашем POM. Если зависимость указана в вашем POM, эта версия будет использоваться в вашей сборке. Если зависимость не указана в вашем POM, будет использоваться версия, которая является ближайшей транзитивной зависимостью. Это объясняется далее в разделе 3.6 « Лучшая сборка с Maven» .

Добавление тестовых зависимостей

Теперь, когда исходный код компилируется, мы должны получить компиляцию и запуск модульных тестов. Добавьте следующие зависимости в нижнюю часть раздела <dependencies> после зависимости junit jar):

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <version>2.0.2</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-beans</artifactId>
      <version>2.0.2</version>
      <scope>test</scope>
    </dependency> 

Мы можем скомпилировать модульные тесты, запустив команду> mvn test-compile, или мы можем запустить модульные тесты, запустив> mvn test в командной строке. Этап тестовой компиляции полезен, когда вам нужно убедиться, что ваши тестовые исходники компилируются, но не хотите запускать свои модульные тесты. Запустив юнит-тесты, вы увидите, что они работают за 6 секунд.

Области зависимости

Вы заметите, что все Jar-файлы, необходимые для модульного тестирования, имеют элемент <scope> test </ scope> как часть их списка зависимостей. Это говорит Maven, что эти jar-файлы необходимы только во время модульного тестирования, но не должны добавляться в POM развертывания. Более подробно это описано на странице « Введение в механизм зависимости» .

Codebase Health с отчетами Maven 2

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

• Javadoc: генерирует Javadoc для проекта
• JXR: генерирует исходный список в стиле javadoc с гиперссылками классов проектов
• Taglist: генерирует список тегов TODO и FIXME, найденных в вашей кодовой базе
• Surefire: генерирует отчет о прохождении / отказе модульного теста
• Cobertura: генерирует отчет о модульном тестировании
• JDepend: генерирует метрики для проекта
• FindBugs: генерирует отчет FindBugs (порог отчета и усилия настраиваются)
• PMD: создает отчет PMD и отчет детектора копирования / вставки PMD.
• Крыса: генерирует отчет инструмента аудита релизов Google

JavaNCSS — это еще один инструмент, который генерирует метрики для проекта, но, к сожалению, ошибка в синтаксическом анализаторе нарушает некоторые функции Java 5.

Скопируйте следующий XML в POM, прямо под разделом <dependencies>:

  <reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jxr-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>taglist-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-report-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>cobertura-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jdepend-maven-plugin</artifactId>
      </plugin>      
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>findbugs-maven-plugin</artifactId>        
        <configuration>
          <threshold>Low</threshold>
          <effort>Max</effort>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-pmd-plugin</artifactId>
        <configuration>
          <linkXref>true</linkXref>
          <sourceEncoding>utf-8</sourceEncoding>
          <minimumTokens>100</minimumTokens>
          <targetJdk>1.5</targetJdk>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>rat-maven-plugin</artifactId>
      </plugin>
    </plugins>
  </reporting>

После того, как вы добавили эти объявления отчета в POM, выполните команду

> мвн сайт

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

Чтобы просмотреть только что созданный сайт, откройте /guice-1.0-src/target/site/index.html и только что созданный сайт появится в вашем браузере. Чтобы просмотреть отчеты, нажмите на ссылку Отчеты проекта, и раздел отчетов развернется. Даже при строгих настройках отчетов Guice выглядит действительно хорошо!

Также можно добавить информацию о SCM, списки рассылки и другую статическую информацию о проекте, которая находится в POM for Guice в центральном хранилище здесь .

Делая Guice в банку

Упаковка Guice

Хотя мы завершили создание POM для Guice, нам все еще нужно сгенерировать guice.jar. Для этого запустите

> мвн пакет

и jar с именем guice-1.0.jar будет находиться в каталоге /guice-1.0-src/target. Созданный Jar можно использовать, но другим пользователям потребуется вручную добавить aopalliance.jar, cglib-nodep-2.2_beta-1.jar и asm-3.0.jar в их путь к классам, и мы не можем использовать Guice в других проектах. Есть несколько вещей, которые мы можем сделать, чтобы справиться с каждой из этих ситуаций:

Установка Guice.jar в локальный репозиторий

Чтобы разрешить использование Guice другими проектами, создаваемыми локально с помощью Maven 2 на вашем компьютере, его необходимо установить в локальный репозиторий. Это делается путем запуска

> установить mvn

и Guice будет установлен в ваш локальный репозиторий в .m2 / repository / com / google / code / guice / guice / 1.0 вместе с файлом POM, который мы сделали до сих пор.

Сборка Guice.jar для распространения

Чтобы создать jar-файл, который может использоваться другими разработчиками без необходимости загружать какие-либо зависимости, мы хотим использовать плагин Maven Assembly Plugin для объединения всех jar-файлов, необходимых для Guice.

Добавьте следующий XML под плагином maven-compiler-plugin в вашем POM:

      <plugin>
        <artifactId>maven-assembly-plugin</artifactId>
        <configuration>
          <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
        </configuration>
      </plugin>

и выполнить команду

> мвн сборка: сборка

Сгенерированный jar с именем guice-1.0-jar-with-dependencies.jar будет в вашем каталоге guice-1.0-src / target. Этот Jar содержит классы из JM ASM 3.0, cglib и aopalliance, включенные в Jar вместе с файлами Guice .class.

Развертывание Guice

Чтобы сделать Guice доступным для репозитория вашей команды (ознакомьтесь с Artifactory , Archiva и Nexus ), используйте плагин Maven Deploy для совместного использования guice-1.0.jar и его POM, укажите репозиторий вашей команды, как описано в разделе «Использование», и выполните его с

> mvn deploy: deploy

Поскольку cglib-node-2.2_beta-1 недоступен в Ibiblio, его также необходимо добавить в репозиторий вашей команды, используя

> mvn deploy: deploy-file

После выполнения этих двух шагов ваши товарищи по команде могут использовать Guice в своих сборках Maven 2 без особых усилий.

Чтобы включить наиболее устойчивое решение, cglib-nodep-2.2_beta-1 должен быть загружен / развернут в центральном репозитории, исключая некоторые усилия, которые вы проделали в этом руководстве.

Использование разных версий зависимых фляг

Использование разных версий зависимых фляг очень легко с Maven. Вам нужно только изменить значение в элементе <version> каждого Jar-файла, который вы хотите обновить, а Maven позаботится обо всем остальном. Хотите использовать более новую версию ASM? Просто замените 3.0 на 3.1 и сделайте> mvn compile Хотите протестировать Guice с более новыми версиями Spring? Просто измените версии Spring Jars с 2.0.2 на 2.5.3, выполните mvn-тест и все. Вам не нужно находить эти файлы Jar и их зависимости, а затем копировать их в папку lib — все это делает Maven. Мы увидим еще больше возможностей управления зависимостями в Maven во второй части.

Генерация дескрипторов проекта IDE

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

> mvn netbeans-freeform: генерировать-netbeans-проект

> мвн идея: идея

> mvn eclipse: затмение

или если вы используете плагин m2eclipse, используйте

> mvn m2eclipse: затмение

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

Вывод

Мы быстро ознакомились с Maven 2, успешно создали POM, который компилирует Guice, создали для него полезный веб-сайт и установили необходимые зависимости, которые недоступны в Ibiblio. Мы также создали Jar, который может использоваться другими разработчиками, и сделали Guice доступным в репозитории команды, который может использоваться партнерами по команде. Кроме того, мы увидели, как легко обновить зависимые файлы JAR в файле POM, просто изменив номера версий зависимостей. В следующей части серии статей мы рассмотрим, как использовать многомодульный механизм сборки Maven.

Ресурсы

Текст заполненного файла pom.xml можно найти здесь .

Страница внешних ресурсов Maven