使用Maven在精简的WAR包中包含特定的JAR文件

Question

我一直遇到一个WAR模块的问题，它很难加载taglib。我一直收到这个异常：

JSPG0047E：无法定位URI为http://www.springframework.org/tags/form的标签库 at com.ibm.ws.jsp.translator.visitor.tagfiledep.TagFileDependencyVisitor.visitCustomTagStart(TagFileDependencyVisitor.java:76) at com.ibm.ws.jsp.translator.visitor.JspVisitor.processJspElement(JspVisitor.java:366) at com.ibm.ws.jsp.translator.visitor.JspVisitor.processChildren(JspVisitor.java:419) at com.ibm.ws.jsp.translator.visitor.JspVisitor.processJspElement(JspVisitor.java:369) ...

经过一番搜索，我发现很多建议是spring jars需要在应用程序的类路径中。我在我的EAR的lib文件夹中检查了一下，确实有spring-web和spring-webmvc。

应该注意的是，EAR是使用skinny WAR构建的，因为它们使用大部分相同的库，所有库文件都在MyAppEAR/lib中，而不是在MyAppEAR/MyWAR1/WEB-INF/lib、MyAppEAR/MyWAR2/WEB-INF/lib、MyAppEAR/MyWAR3/WEB-INF/lib等。

最终，我确实成功解决了这个缺少taglib的错误，但我不得不将spring-web和spring-webmvc移动到MyAppEAR/MyWAR1/WEB-INF/lib中。

所以我有几个问题：

1. Is this the only way to fix this problem?

2. If so, how can I build a sort-of skinny WAR using maven? Currently, the EAR part of the POM looks like this:

   <plugin>
     <artifactId>maven-ear-plugin</artifactId>
     <version>2.8</version>
     <configuration>
       <applicationName>MyAppEAR</applicationName>
       <defaultLibBundleDir>lib</defaultLibBundleDir>
       <skinnyWars>true</skinnyWars>
   

我想我可以关闭精简的WAR包，然后再通过其他步骤从WAR文件中删除所有库，并将它们复制到MyAppEAR/lib目录下，除了Spring Web Jars。但我希望有更好的解决方案。

- FrustratedWithFormsDesigner

---

很好的问题。当我在JUnit中运行针对Jetty（以编程方式实例化）的Selenium测试时，我遇到了同样的问题。我将'src/main/webapp'提供给Jetty，它期望在那里找到这些库。仅仅在类路径上（这些库由Maven放置在类路径上）似乎不够。 - Sander Verhagen

@SanderVerhagen：也许这与您在Jetty上的问题有关：http://stackoverflow.com/questions/6020495/embedded-jetty-fails-to-load-jsp-taglibs-when-classpath-specified-in-jar - FrustratedWithFormsDesigner

这是一个非常好的问题。我在问自己，如果瘦WAR仍然是一个好的解决方案，因为它们往往会引起问题。有关某些JAR必须存在于“WEB-INF / lib”中的原因，请参见[此问题/答案]（https://dev59.com/UnA75IYBdhLWcg3w_uqD）。 - Martin Höller

Answer 1

我自己也遇到了同样的问题-当我的Spring JAR文件在ear/lib文件夹中时，我就无法访问Spring或Sitemesh的TLDs！将类路径包含在MANIFEST中会导致我的应用服务器失控（因为所有依赖项都被加载两次）。

（是的，我还在我的maven-ear-plugin中设置了skinnyWars为true。）

我唯一可以解决这个问题的方法是通过在maven-war-plugin的配置中包括Spring和sitemesh来解决。

<packagingExcludes>%regex[WEB-INF/lib/(?!spring|sitemesh).*.jar]</packagingExcludes>

我找到的方案可能不是最优雅的解决方案，但是对系统影响最小。

这是我的完整配置：

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.1.1</version>
            <configuration>

                <!--
                Q. Why is this set?
                A. maven-ear-plugin in our EAR modules have `skinnyWars` enabled to that WAR files 
                   would not include any third-party libraries in the WAR's WEB-INF/lib folder, however 
                   this does not work for ejbs (like our own EJB modules).

                   We'll need to exclude them from here anyway (except for a few select JARS)...
                -->                 
                <packagingExcludes>%regex[WEB-INF/lib/(?!spring|sitemesh).*.jar]</packagingExcludes>

                <archive>
                    <manifest>
                        <addClasspath>false</addClasspath>
                    </manifest>
                </archive>
            </configuration>
        </plugin>

---

PS. 我的设置是 JBoss EAP 6.x 和一个包含多个 EJB、WAR 和第三方 JAR 的 ear 文件。

- Matthew Cachia

Answer 2

我想我已经让它工作了。

在WAR的POM文件中：

<plugin>
  <artifactId>maven-war-plugin</artifactId>
    <version>2.2</version>
    <configuration>
      <warSourceDirectory>src/main/webapp</warSourceDirectory>
      <packagingExcludes>WEB-INF/lib/*.jar,WEB-INF/*.xmi</packagingExcludes>
      <archive>
        <manifest>
             <addClasspath>true</addClasspath>
             <classpathPrefix>../../WEB-INF/lib/</classpathPrefix>
       </manifest>
      </archive>
    </configuration>
</plugin>

这会导致生成的WAR文件具有一个META-INF/MANIFEST.MF文件，其中包含类路径条目，看起来像是../WEB-INF/lib/$someJarFile - 这是从WAR到EAR库文件夹的相对路径。我猜WAR必须指定类路径，仅在EAR中拥有库是不够的。

- FrustratedWithFormsDesigner

---

虽然您的建议可能有效，但我认为它是一种hack。如果WAR文件在EAR文件之外，那么它将不再部署。这就是为什么maven wiki建议在EAR插件中修复此问题，也是EAR插件获得skinnyWars参数的原因。因此，在我看来，问题应该在EAR端而不是WAR端解决。不幸的是，我现在无法提供更好的解决方案 :( - Martin Höller

@MartinHöller：我同意，我并不是很喜欢它。我们在较新版本的WebSphere上开展新的EAR项目运气更好。这主要是一个旧项目一直在出问题。 - FrustratedWithFormsDesigner