Maven: спецификация javax.servlet развернута - PullRequest
1 голос
/ 25 июня 2011

У меня есть веб-приложение, настроенное на Maven, которое использует библиотеку, также настроенную на Maven, и когда я упаковываю geronimo-servlet_3.0_spec-1.0.jar, включается в WEB-INF / lib, и я не понимаю, почему.

Я проверяю библиотеку с зависимостью mvn: tree

$ mvn dependency:tree | grep geronimo
[INFO] +- org.apache.geronimo.specs:geronimo-servlet_3.0_spec:jar:1.0:provided

Я проверяю мое веб-приложение:

$ mvn dependency:tree | grep geronimo
$

Однако, когда я запускаю mvn: package, файл включаетсяв WEB-INF / lib.

Когда я запускаю mvn tomcat: run, я вижу:

INFO: validateJarFile (/ home / stivlo / workspace / private / src / main / webapp / WEB-INF / lib / geronimo-servlet_3.0_spec-1.0.jar) - файл не загружен.См. Servlet Spec 2.3, раздел 9.7.2.Оскорбляющий класс: javax / servlet / Servlet.class

Почему и как избежать?Спасибо.

ОБНОВЛЕНИЕ 1 : по запросу я добавляю 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>org.obliquid</groupId>
    <artifactId>test-webapp</artifactId>
    <packaging>war</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>private webapp</name>
    <url>http://maven.apache.org</url>

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

    <repositories>
        <!-- For Jakarta ORO -->
        <repository>
            <id>mvnsearch</id>
            <name>Maven Search</name>
            <url>http://www.mvnsearch.org/maven2/</url>
        </repository>
    </repositories>

    <dependencies>

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.8.2</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.obliquid.helpers</groupId>
            <artifactId>obliquid-helpers</artifactId>
            <version>0.9-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.4</version>
            <scope>provided</scope>
        </dependency>

    </dependencies>

    <build>
        <finalName>private</finalName>
    </build>

</project>

ОБНОВЛЕНИЕ 2 : Я последовал совету СтивенаC и изменил раздел сборки следующим образом:

<build>
    <finalName>private</finalName>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war</artifactId>
            <version>2.1</version>
            <configuration>
                <overlays>
                    <overlay>
                        <groupId>org.obliquid</groupId>
                        <artifactId>test-webapp</artifactId>
                        <excludes>
                            <exclude>WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar</exclude>
                        </excludes>
                    </overlay>
                </overlays>
            </configuration>
        </plugin>
    </plugins>
</build>

Однако Geronimo * .jar все еще включен.Полагаю, я допустил ошибку в этой конфигурации.

ОБНОВЛЕНИЕ 3 : Стивен С. говорит, что я должен использовать

groupId artifactId объектаWAR-файл, содержащий JAR-файлы, которые вы пытаетесь исключить.

Я не знал, что WAR-файлы могут иметь groupId и artifactId, фактически в моем pom.xmlне вижу никого.Мой проект строит файл WAR и имеет groupId и artifactId, и это были те, которые я тестировал выше без успеха.

Зависимость, вызывающая проблему, следующая (это JAR, а не WAR):

<dependency>
    <groupId>org.obliquid.helpers</groupId>
    <artifactId>obliquid-helpers</artifactId>
    <version>0.9-SNAPSHOT</version>
    <scope>compile</scope>
</dependency>

Если я пытаюсь использовать groupId и artifactId, перечисленные в этой зависимости, у меня возникает следующая ошибка:

[ОШИБКА] Не удалось выполнить цель org.apache.maven.plugins: maven-war-plugin: 2.1.1: war (default-war) для проекта test-webapp: overlay [id org.obliquid.helpers: obliquid-helpers] не является зависимостью проекта.-> [Помощь 1]

Если я попытаюсь использовать groupId и artifactId JAR, включенного в org.obliquid.helpers:

<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-servlet_3.0_spec</artifactId>)

У меня та же ошибка.

[ОШИБКА] Не удалось выполнить цель org.apache.maven.plugins: maven-war-plugin: 2.1.1: война (default-war) в проекте test-webapp: overlay [id org.apache.geronimo.specs: geronimo-servlet_3.0_spec] не является зависимостью проекта.-> [Помощь 1]

Читая документацию по плагину War, я нашел раздел о создании скинов WARS .Поэтому я попробовал следующее:

<build>
    <finalName>private</finalName>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.1.1</version>
            <configuration>
                <packagingExcludes>WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar</packagingExcludes>
            </configuration>
        </plugin>
    </plugins>
</build>

Все еще без какого-либо успеха, geronimo-servlet_3.0_spec-1.0.jar все еще там!

<groupId>org.obliquid.helpers</groupId>
<artifactId>obliquid-helpers</artifactId>

[ОШИБКА] Не удалось выполнить цель org.apache.maven.plugins: maven-war-plugin: 2.1.1: война (default-war) для проекта test-webapp: overlay [id org.obliquid.helpers: obliquid-helpers] не является зависимостью проекта.-> [Помощь 1]

<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-servlet_3.0_spec</artifactId>

[ОШИБКА] Не удалось выполнить цель org.apache.maven.plugins: maven-war-plugin: 2.1.1: война (default-war) при тестировании проекта-webapp: overlay [id org.apache.geronimo.specs: geronimo-servlet_3.0_spec] не является зависимостью проекта.-> [Помощь 1]

ОБНОВЛЕНИЕ 4 : я обнаружил, что файл target / private.war не является zip-файлом target / private /, но исключения выполняются во время упаковкиа не путем удаления файлов в target / private / - это означает, что я должен повторно протестировать все, что я делал раньше.

  • Предложение gouki: не работает, JARвсе еще там же в файле WAR.
  • Предложение Стивена С., возможно, неправильно понято: на самом деле я только что заметил, что pom.xml всегда недействителен независимо от того, какой groupId / artifactId я положил из трех описанных выше возможностей.Таким образом, они не работали для меня.
  • То, что я нашел в документации (упаковка исключает), работает.

Теперь, если бы мне пришлось выбирать один из его ответов, я бы выбрал Стивена С., потому что он помог мне указать на документацию плагина WAR (я читал не в том месте). Однако я бы принял ответ, который не работает, по крайней мере, так, как я пытался (вероятно, неправильно). Поэтому я не собираюсь принимать какой-либо ответ и сам добавляю новый ответ с окончательной рабочей конфигурацией.

ОБНОВЛЕНИЕ 5 : Я публикую соответствующую часть pom.xml помощников по obliquid, в которой упоминается geronimo-servlet_3.0_spec. Я пометил его как необязательный и с предоставленной областью действия, но он по-прежнему включается веб-приложением, если я не отмечу его как «packagingExclude» в конфигурации maven-war-plugin.

<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>org.obliquid.helpers</groupId>
  <artifactId>obliquid-helpers</artifactId>
  <version>0.9-SNAPSHOT</version>
  <packaging>jar</packaging>
  <name>obliquid-helpers</name>
  <url>http://maven.apache.org</url>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <repositories>
    [...]
  </repositories>

  <dependencies>
    [...]

    <dependency>
      <groupId>org.apache.geronimo.specs</groupId>
      <artifactId>geronimo-servlet_3.0_spec</artifactId>
      <version>1.0</version>
      <scope>provided</scope>
      <optional>true</optional>
    </dependency>

  </dependencies>

</project>

Ответы [ 3 ]

1 голос
/ 25 июня 2011

Очевидно, что что-то зависит от этого файла JAR. Если он не отображается в дереве зависимостей, возможно, это связано с зависимостью файла WAR вашего веб-приложения от другого файла WAR, имеющего эту зависимость.

Если это так, то вы можете добавить <excludes> к элементу <overlay> дескриптора сборки для плагина WAR-файла; например,

...
<build>
  <finalName>webapp</finalName>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.1</version>
        <configuration>
          <overlays>
            <overlay>
              <groupId>xxx</groupId>
              <artifactId>yyy</artifactId>
              <excludes>
                <exclude>WEB-INF/lib/whatever.jar</exclude>
              </excludes>
            </overlay>
          </overlays>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...

Если вы используете оверлейные файлы WAR, вы всегда должны включать цель clean в сборку. В противном случае вы можете получить старые зависимости в файле WAR. (IIRC, в выводе Maven появляется предупреждение каждый раз, когда вы создаете накладываемый WAR без очистки!)

На самом деле, это может быть основной причиной ваших проблем. Например, если раньше у вас было «geronimo» как обычная зависимость, и с тех пор вы не запускали mvn clean, файл JAR все еще может зависать.

0 голосов
/ 26 июня 2011

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

Читая документацию к плагину WAR, особенно раздел war: war mojo, я нашел пример того, как создавать Skinny WAR, что и помогло. Ниже приведена рабочая конфигурация, которая будет добавлена ​​в раздел сборки:

<build>
    <finalName>private</finalName>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.1.1</version>
            <configuration>
                <packagingExcludes>WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar</packagingExcludes>
                <archive>
                    <manifest>
                        <addClasspath>true</addClasspath>
                        <classpathPrefix>lib/</classpathPrefix>
                    </manifest>
                </archive>
            </configuration>
        </plugin>
    </plugins>
</build>

Часть архива, вероятно, на самом деле не нужна, но я выясню, когда разверну WAR. Часть, которая делает трюк - это тег packageExcludes, который может содержать список токенов, разделенных запятыми , которые исключаются из WAR перед упаковкой .

0 голосов
/ 25 июня 2011

Исходя из вашего pom.xml, единственная зависимость, которая может зависеть от сервлета geronimo, это

 <dependency>
        <groupId>org.obliquid.helpers</groupId>
        <artifactId>obliquid-helpers</artifactId>
        <version>0.9-SNAPSHOT</version>
        <scope>compile</scope>
    </dependency>

Можете ли вы попробовать исключить геронимо в этой зависимости?

  <dependency>
            <groupId>org.obliquid.helpers</groupId>
            <artifactId>obliquid-helpers</artifactId>
            <version>0.9-SNAPSHOT</version>
            <scope>compile</scope>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.geronimo.specs</groupId>
                    <artifactId>geronimo-servlet_3.0_spec</artifactId>
                 </exclusion>
             </exclusions>
        </dependency>
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...