在与Maven的skinny WARs中包含特定的JAR文件

我在WAR模块以及加载taglib时遇到了一些问题。我一直得到这样的例外：

JSPG0047E: Unable to locate tag library for 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) ...

---

我想我可以关闭skinny WARs，然后采取其他步骤从WAR文件中删除所有库，并将它们复制到MyAspect/lib（spring web jars除外），但我希望有更好的解决方案。

我想我已经成功了

在战争的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>

maven战争插件
2.2
src/main/webapp
WEB-INF/lib/*.jar，WEB-INF/*.xmi
真的
../../WEB-INF/lib/

---

这会导致生成的WAR文件具有一个

META-INF/MANIFEST.MF

文件，其中的类路径条目看起来像

。/WEB-INF/lib/$someJarFile

——这是从WAR到EAR库文件夹的相对路径。我想WAR需要指定类路径，将库放在EAR中是不够的。

我自己也有同样的问题-当我的Spring JAR文件在我的

EAR/lib

文件夹中时，我无法访问Spring或Sitemesh的TLD

在清单中包含类路径导致我的应用程序服务器失控（因为所有依赖项都被加载了两次）

（是的，我的

maven-ear插件中也将
skinnyWars
设置为true）

我可以绕过这个问题的唯一方法是将
Spring
和
sitemesh
包含在
maven-war-plugin
的配置中：

<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>

%regex[WEB-INF/lib/（？！spring | sitemesh）。*.jar]

这不是最优雅的解决方案，但却是我能找到的破坏性最小的解决方案

这是我的完整配置：

<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>


org.apache.maven.plugins
maven战争插件
2.1.1
%regex[WEB-INF/lib/（？！spring | sitemesh.*.jar]
假的


另外，我的设置是JBoss EAP 6.x和一个ear文件，其中包含几个EJB、WAR和第三方JAR。
好问题。在JUnit中对Jetty（以编程方式实例化）运行Selenium测试时，我也遇到同样的问题。我为Jetty提供了“src/main/webapp”，它希望在那里找到这些库。仅仅在类路径上（这些库由Maven放在类路径上）似乎是不够的。@SanderHagen:也许这与您在Jetty上的问题有关：这是一个非常好的问题。我在问自己，如果骨瘦如柴的战争仍然是一个很好的解决方案，因为它们往往会制造问题。看看为什么有些坛子必须生活在<代码> WebINF/LIB 。当你的建议工作时，我会认为这是一个黑客行为。如果战争在耳边，它就不会再部署了。这就是为什么建议在EAR插件中修复这个问题，这就是为什么EAR插件获得了成功。因此，我认为这个问题应该解决在耳朵方面而不是战争方面。不幸的是，我现在无法提供更好的解决方案：（@MartinHöller:我同意，我并不太喜欢它。我们在WebSphere的新版本上有了新的EAR项目，运气更好。主要是这一个遗留项目带来了问题。