it-roy-ru.com

Maven WAR зависимость

Я пишу проект для приемочного тестирования, и по разным причинам это зависит от другого проекта, который упакован как WAR. Мне удалось распаковать WAR-файл, используя плагин maven-dependency-plugin, но я не могу включить в свой проект распакованные WEB-INF/lib/*.jar и WEB-INF/classes/*, чтобы включить в путь к классам, поэтому сборка не удалась. Есть ли способ включить эти файлы в путь к классам, или есть лучший способ зависеть от WAR?

Большое спасибо.

79
deelo55

Существует еще один вариант, начиная с Maven-War-плагин 2.1-альфа-2. В вашем проекте WAR:

<plugin>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.1.1</version>
    <configuration>
        <attachClasses>true</attachClasses>
    </configuration>
</plugin>

Это создает артефакт классов, который вы можете использовать в проекте приемочных тестов:

<dependency>
    <groupId>your-group-id</groupId>
    <artifactId>your-artifact-id</artifactId>
    <version>your-version</version>
    <classifier>classes</classifier>
</dependency>
110
Christoph Leiter

Действительно, по замыслу Maven не разрешает переходные зависимости войны, объявленной зависимостью проекта. На самом деле есть проблема, MNG-1991 , но она не будет решена в Maven 2.x и Я не уверен что Я не знаю, позволяют ли оверлеи решить эту проблему. Мое понимание предлагаемого решения заключается в дублировании зависимостей, например, в проекте типа pom.


(Правка: После еще нескольких копаний, я нашел кое-что интересное в этот поток , который я цитирую ниже:

В прошлом месяце я помогал с разработкой проекта AppFuse, где мы активно используем функцию наложения войны в военном плагине Maven. Это действительно изящная особенность!

Чтобы получить максимальную мощность с помощью наложения войны, я разработал плагин Warpath, который позволяет проектам использовать военные артефакты в качестве полноценных зависимостей. Вкратце:

1) Содержимое каталога/WEB-INF/classes в артефактах зависимости от войны может быть включено в путь к классам проекта для обычных задач компиляции и т.д.
2) Переходные зависимости от артефактов зависимости от войны становятся доступными для использования другими плагинами, например, compile и ear - так что больше не нужно включать все зависимости при создании тощих войн!

Плагин в настоящее время активно используется в проекте AppFuse в течение последних нескольких месяцев, и я чувствую, что он находится в точке, где он может быть использован и стабилен. Будет ли команда военного плагина заинтересована во включении функциональности warpath в военный плагин? Казалось бы, это самое естественное место для его размещения.

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

[...]
<build>
  <plugins>
    <plugin>
      <groupId>org.appfuse</groupId>
      <artifactId>maven-warpath-plugin</artifactId>
      <version>1.0-SNAPSHOT</version>
      <extensions>true</extensions>
      <executions>
        <execution>
          <goals>
            <goal>add-classes</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>
[...]

И добавьте зависимости войны, которые вы хотите включить в classpath, как зависимости типа warpath :

[...]
<dependencies>
  <dependency>
    <groupId>org.appfuse</groupId>
    <artifactId>appfuse-web</artifactId>
    <version>2.0</version>
    <type>war</type>
  </dependency>
  <dependency>
    <groupId>org.appfuse</groupId>
    <artifactId>appfuse-web</artifactId>
    <version>2.0</version>
    <type>warpath</type>
  </dependency>
</dependencies>
[...]

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

Я бы попробовал.)

23
Pascal Thivent

Используйте оверлеи . Во-первых, ваш тестовый проект должен иметь также упаковку war.

Объявите зависимость военного проекта, который вы хотите протестировать:

<dependency>
    <groupId>${project.groupId}</groupId>
    <artifactId>your-project-arftifactId</artifactId>
    <version>${project.version}</version>  
    <type>war</type>
    <scope>test</scope>
</dependency>

затем настройте оверлей maven-war-plugin:

<plugins>
    <plugin>
        <groupId>org.Apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
            <webResources>
                <resource>
                    <directory>${basedir}/src/main/webresources</directory>
                    <filtering>true</filtering>
                </resource>
            </webResources>
            <overlays>
                <overlay/>
                <overlay>
                    <groupId>your.group</groupId>
                    <artifactId>your-project-artifactId</artifactId>
                </overlay>
            </overlays>
        </configuration>
    </plugin>

В приведенном выше примере в тестовом проекте я перезаписываю файлы конфигурации веб-ресурсов (например, conxtext и т.д.).

РЕДАКТИРОВАТЬ: Это решение не было протестировано с Maven 3.

13
cetnar

Хороший вопрос, Джастин. Это фактически помогло мне решить мою проблему, а именно: включить войну в Ассамблею и включить все ее переходные зависимости. Я не мог продублировать зависимость от войны как 'jar', как вы предложили, так как плагин Assembly не нашел бы jar, на который ссылается этот groupId/artefactId, но

  • дублирование зависимости от войны как типа pom

работает! Война и ее переходные зависимости не включены в Ассамблею. Чтобы исключить (теперь также появляющийся) pom-файл, мне пришлось добавить исключающий элемент, например так:

  <excludes>
    <exclude>*:pom</exclude>
  </excludes>

в мой файл Assembly.xml.

Я думаю, что это также может быть обходной путь для первоначального вопроса этой темы.

4
Niels