Maven: развернута спецификация javax.servlet

У меня есть веб-приложение, настроенное с помощью 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, я вижу:

ИНФОРМАЦИЯ: validateJarFile (/home/stivlo/workspace/private/src/main/webapp/WEB-INF/lib/geronimo-servlet_3.0_spec-1.0.jar) - jar не загружен. См. Спецификацию сервлета 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. Я последовал совету Стивена Си и изменил раздел сборки следующим образом:

<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 - идентификатор артефакта файла 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: war (default-war) в проекте test-webapp: overlay [id org.apache.geronimo.specs: geronimo- servlet_3.0_spec] не является зависимостью проекта. -> [Справка 1]

Читая документацию по плагину 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>
            </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: war (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: war (default-war) в проекте test-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 я поставил из трех возможностей, описанных выше. Так что у меня они не работали.
  • То, что я нашел в документации (PackingExcludes), работает.

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

ОБНОВЛЕНИЕ 5: я публикую соответствующую часть pom.xml obliquid-helpers, в которой упоминается geronimo-servlet_3.0_spec. Я пометил его как необязательный и с предоставленной областью действия, но он все равно включается в веб-приложение, если я не помечу его как «packageExclude» в конфигурации 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>

java maven tomcat
person stivlo    schedule 25.06.2011    source источник
comment
Конечно, я добавляю это к ответу.   -  person stivlo    schedule 25.06.2011

Ответы (3)


arrow_upward
1
arrow_downward

Очевидно, что что-то зависит от этого JAR-файла. Если он не отображается в дереве зависимостей, возможно, это связано с зависимостью вашего WAR-файла webapp от другого 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 все еще может зависать.

person Stephen C    schedule 25.06.2011
comment
Спасибо, я добавил исключение, как вы предложили, но geronimo * .jar все еще включен. Думаю, я совершил какую-то ошибку ... Когда вы говорите: ‹groupId› xxx ‹/groupId› ‹artifactId› yyy ‹/artifactId›, это означает мое веб-приложение? Ставлю те из своего webapp. - person stivlo; 25.06.2011
comment
Нет. Я имею в виду groupId - идентификатор артефакта файла WAR, который содержит файлы JAR, которые вы пытаетесь исключить. Прочтите документацию плагина файла Maven WAR !! - person Stephen C; 26.06.2011
comment
Хорошо, я уже много читал о Maven, но недостаточно, по вашему предложению я пошел сюда, чтобы прочитать больше maven.apache.org/plugins/maven-war-plugin/war-mojo.html - Я пробовал три разные вещи, и все они потерпели неудачу - здесь я не могу форматировать текст правильно, я собираюсь обновить вопрос. - person stivlo; 26.06.2011
comment
Упс, обновление: похоже, что тонкая война работает. Все JAR-файлы находятся в каталоге target / private /, но не добавляются в каталог target / private.war. Я не знал, что они могут быть другими. Мне не хватает опыта работы с Maven. Я перепробую все конфигурации и внесу поправки в ОБНОВЛЕНИЕ 3. - person stivlo; 26.06.2011

arrow_upward
0
arrow_downward

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

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

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

  <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>
person gouki    schedule 25.06.2011
comment
Да, это именно то, что странно, это то, что помечено как предоставленное, что означает, что afaik не должен быть включен в упаковку. Теперь я пробую ваше решение и сообщаю вам, спасибо. - person stivlo; 25.06.2011
comment
Я не знаю почему, но даже добавив исключение внутри зависимости, geronimo-servlet_3.0_spec-1.0.jar все еще существует :-( - person stivlo; 25.06.2011
comment
Возможно, вы все равно сможете использовать <dependencyManagement>, чтобы он был «предоставлен». - person Donal Fellows; 25.06.2011
comment
попробуйте: mvn clean package -DskipTests; попробуйте очистить целевой каталог, чтобы убедиться, что в нем нет geronimo jar из предыдущей сборки. - person gouki; 25.06.2011
comment
Выполните поиск в целевом каталоге, если в нем есть geronimo jar. Если есть, выполните mvn clean, затем запустите mvn package. - person gouki; 26.06.2011
comment
Я всегда запускал mvn clean перед любым пакетом mvn, чтобы быть уверенным. - person stivlo; 26.06.2011

arrow_upward
0
arrow_downward

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

Читая документацию по плагину 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 перед упаковкой.

person stivlo    schedule 26.06.2011
comment
Я хотел бы отметить, что мой совет основывался на предположении, что вы использовали наложения файлов WAR ... чего вы не делаете. - person Stephen C; 26.06.2011
comment
Я также думаю, что вы не дошли до сути этого. Почему этот JAR-файл вообще был зависимостью? Упоминалось ли это в каких-либо файлах POM? Упоминается ли это в каких-либо файлах POM ваших иждивенцев? Вы используете какой-то прикольный плагин, который добавляет иждивенца за вашей спиной? Иждивенцев не затягивают, если где-то не упоминается ... - person Stephen C; 26.06.2011
comment
Я вижу, в вопросе, который я упоминаю, я использую библиотеку, также настроенную с Maven, возможно, мне следовало также сказать, что она была упакована как JAR ... Насчет второго комментария: вы правы, я до сих пор не знаю, почему это был включен в первую очередь. Выкладываю pom.xml obliquid-helpers - person stivlo; 26.06.2011
comment
Я опубликовал ОБНОВЛЕНИЕ 5 с pom.xml obliquid-helpers, которое включено в веб-приложение. - person stivlo; 26.06.2011