IBM®
Перейти к тексту
    в России и странах СНГ [изменить]    Условия использования
 
 
   
    Главная страница    Продукты    Услуги и решения    Поддержка и загрузка    Мой профиль    
Перейти к тексту

developerWorks Россия  >  Технология Java | Open source  >

Введение в Apache Maven 2

developerWorks
На предыдущую страницуСтраница 9 из 16 На предыдущую страницу

Опции документа

Исходные тексты примера


Выскажите мнение об этом учебном пособии

Помогите нам улучшить содержание


Практика по Maven 2 - работа по сборке нескольких проектов

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

Усложнение примера NumOps

Второй пример представляет собой расширенный пример NumOps. Добален новый класс SubOps для поддержки вычитания и новый класс MulOps для поддержки умножения.

Однако интерфейс Operation и класс AddOps теперь удалены из проекта NumOps. Вместо этого они помещены вместе с новыми классами SubOps и MulOps в новый проект OpsImp. На Рисунке 7 показана связь между проектами NumOps и OpsImp:


Рисунок 7. Связь между NumOps и OpsImp
Связь между NumOps и OpsImp

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

SubOps, приведенный в Листинге 13, кодируется аналигочно AddOps. MulOps, непоказанный здесь, тоже похож на них; для получения подробной информации обратитесь к дистрибутивам кодов (см. Загрузка).


Листинг 13. Новый класс SubOps реализует интерфейс Operation
                    
package com.ibm.devworks;

public class SubOps implements Operation {
   public int op(int a, int b) {
      return a-b;
   }
   public String getDesc() {
      return "minus";
   }
}

Конструктор проектаNumOps теперь несколько изменен для создания экземпляра SubOps и экземпляра MulOps. Вы можете посмотреть дистрибутивы исходного кода для более подробной информации.



В начало


Создание главного проекта

Для работы с этими двумя проектами был создан главный проект в каталоге, на уровень выше каталогов с проектами NumOps и OpsImp. Как проект NumOps, так и проект OpsImp используют стандартную типологию каталогов проектов Maven. На верхнем уровне каталог состоит только из одного файла pom.xml. На Рисунке 8 показана структура с новым подкаталогом непосредственно под главной директорией:


Рисунок 8. Структура каталогов многомодульного проекта
Структура каталогов многомодульного проекта

Вы можете найти код этого примера многомодульного проекта в подкаталоге example2 дистрибутива кода (см. Загрузка). Файл pom.xml, находящийся на верхнем уровне, показан в Листинге 14:


Листинг 14. Файл 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/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.ibm.devworks</groupId>
  <artifactId>mavenex2</artifactId>
  <packaging>pom</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Maven Example 2</name>
  <url>http://maven.apache.org</url>
<modules>
 <module>NumOps</module>
 <module>OpsImp</module>
</modules>
   <build>
    <plugins>
      <plugin>
        <artifactId>maven-compiler-plugin</artifactId>   
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
<dependencyManagement>
                    <dependencies>
                        <dependency>
                          <groupId>com.ibm.devworks</groupId>
                          <artifactId>OpsImp</artifactId>
                          <version>${project.version}</version>
                        </dependency>
                      </dependencies>
                    </dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Новые фрагменты кода выделены жирным шрифтом. Во-первых, ID артефакта главного проекта - mavenex2, а тип его пакетирования - pom. Это сигнализирует Maven 2 о том, что этот проект является многомодульным.

Тэг <modules> затем указывает два модуля, включенных в проект: NumOps и OpsImp.

Подмодули этого главного проекта могут наследовать свойства из файла pom.xml. Более того, ни одному модулю не надо объявлять связь с JUnit, даже если они оба содержат модули тестирования. Это происходит по тому, что они наследуют связь с JUnit, определенную на верхнем уровне.

Тэг <dependencyManagement> не определяет используемые данным модулем связи. Вместо этого он используется в основном подмодулями. Подмодули могут определить связь с любой записью внутри тэга <dependencyManagement> без указания специального номера версии. Это удобно, так как сокращает количество необходимых изменений при изменении номера версии связей деревом проектов. В этом случае, номер версии проекта OpsImp определяется при помощи ${project.version}. Это параметр, который будет заполняться подходящими значениями во время работы с Maven.



В начало


Наследование от главного POM

Спустившись уровнем ниже в директорию OpsImp, рассмотрим файл pom.xml этого модуля, приведенный в Листинге 15:


Листинг 15. Файл pom.xml для нового проекта OpsImp
                                        
<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/maven-v4_0_0.xsd">
  <parent>
   <groupId>com.ibm.devworks</groupId>
    <artifactId>mavenex2</artifactId>
    <version>1.0-SNAPSHOT</version>
   </parent> 
  <modelVersion>4.0.0</modelVersion>
  <artifactId>OpsImp</artifactId>
  <packaging>jar</packaging>
 </project>

Элемент <parent> определяет главный POM, от которого наследует этот модуль. Наследование от родительского модуля намного упрощает этот pom.xml. Все что вам нужно - переопределить ID артефакта и упаковку. Этот модуль наследует родительскую связь: модуль JUnit.

pom.xml в NumOps также наследует свойства родителей и также достаточно прост. Этот pom.xml показан в Листинге 16:


Листинг 16. Наследование POM в pom.xml для проекта NumOps
                                        
<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/maven-v4_0_0.xsd">
  <parent>
   <groupId>com.ibm.devworks</groupId>
    <artifactId>mavenex2</artifactId>
    <version>1.0-SNAPSHOT</version>
   </parent>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>NumOps</artifactId>
  <packaging>jar</packaging>
  <dependencies>
                        <dependency>
                          <groupId>com.ibm.devworks</groupId>
                          <artifactId>OpsImp</artifactId>
                         </dependency>
                      </dependencies>
</project>

Изучение действующего POM
Что бы вы не наследовали от POM верхнего уровня, вы всегда можете узнать, как на самом деле выглядит ваш pom.xml после подключения всех унаследованных элементов. Командой для просмотра "действующего POM" является mvn help:effective-pom. Вы увидите некоторые элементы, которые сами вы не указывали. Они унаследованы от Super POM. pom.xml каждого проекта неявно наследует от встроенного в Maven Super POM .

В POM проекта NumOps есть одна интересная деталь - определение OpsImp как связи. Заметьте, что не указано никакого номера версии для этой связи. Предпочитаемый номер версии уже определен в родительском элементе <dependencyManagement>.

На верхнем уровне проекта вы теперь можете выполнить команду mvn compile, чтобы скомпилировать оба модуля, или же команду mvn test, чтобы выполнить тестирование обоих модулей. Вы также можете запустить mvn install для установки упакованных модулей в ваш локальный каталог. Это позволит любому модулю, связанному с ним, установить с ним связь без необходимости получить доступ к исходному коду.



В начало



На предыдущую страницуСтраница 9 из 16 На предыдущую страницу
    IBM в России Конфиденциальность Контакты