Home/ Questions/Q 8214475
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T11:28:32+00:00

I have a project where 3 war-modules are packaged in an ear-module. My problem

  • 0

I have a project where 3 war-modules are packaged in an ear-module. My problem is that each of the library jars are included in each of the war-modules, as well as in the ear-module, which makes the resulting ear-file really large (at the moment about 190MB).

I followed the tutorial on making skinny wars with maven here: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html

With this, I managed to get the size of the ear down to around 45MB, which is good, but when i tried to deploy to glassfish it complained about some missing classes.

I turns out that this was due to a dependency to appfuse-struts, which is packaged as a war-file. This is included using a warpath dependecy in one of the war-projects.

Since the tutorial on making skinny wars stated that all dependencies found in the wars must also be defined in the ear. I tried this, but the appfuse-struts dependency being a warpath made this not work. (When adding only the war dependency to the ear pom it complains that it doesn’t find some of the classes, and when adding the warpath dependency as well maven complains that it does not know what warpath is.)

How to create an ear with skinny wars, when the wars use warpath dependencies?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think I might have found a solution:

    In the skinny wars tutorial, one is supposed to add WEB-INF/lib/*.jar to packagingExcludes. Then, all the dependencies were to be added in the ear-configuration, making it available to the jars.

    The problem is that the war-packaged dependency won’t have its transitive dependencies added to the ear’s lib folder, so they either need to find their way into the ear lib folder, or the WEB-INF/lib folder of the war package.

    I chose to go with the last one, adding them to the WEB-INF/lib of the war-file.

    To do this, first get a dependency tree of the war project that contains war/warpath resources, by doing a mvn dependency:tree.

    Next, find the warpath dependecy. In my case, it looked like this:

          +- org.appfuse:appfuse-struts:warpath:2.0.2:compile
      |  +- org.appfuse:appfuse-web-common:war:2.0.2:compile
      |  +- org.appfuse:appfuse-web-common:warpath:2.0.2:compile
      |  +- displaytag:displaytag:jar:1.1.1:compile
      |  |  \- org.slf4j:jcl104-over-slf4j:jar:1.4.2:compile
      |  +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
      |  +- org.apache.commons:commons-io:jar:1.3.2:compile
      |  +- org.appfuse:appfuse-service:jar:2.0.2:compile
      |  |  +- velocity:velocity:jar:1.4:compile
      |  |  |  \- velocity:velocity-dep:jar:1.4:runtime
      |  |  +- org.codehaus.xfire:xfire-java5:jar:1.2.6:compile
      |  |  |  +- org.codehaus.xfire:xfire-aegis:jar:1.2.6:compile
      |  |  |  |  \- net.java.dev.stax-utils:stax-utils:jar:20040917:compile
      |  |  |  +- org.codehaus.xfire:xfire-annotations:jar:1.2.6:compile
      |  |  |  +- xfire:xfire-jsr181-api:jar:1.0-M1:compile
      |  |  |  \- org.codehaus.xfire:xfire-core:jar:1.2.6:compile
      |  |  |     +- stax:stax-api:jar:1.0.1:compile
      |  |  |     +- org.codehaus.woodstox:wstx-asl:jar:3.2.0:compile
      |  |  |     \- commons-httpclient:commons-httpclient:jar:3.0:compile
      |  |  \- org.codehaus.xfire:xfire-spring:jar:1.2.6:compile
      |  |     +- org.apache.xbean:xbean-spring:jar:2.8:compile
      |  |     \- org.codehaus.xfire:xfire-xmlbeans:jar:1.2.6:compile
      |  |        \- xmlbeans:xbean:jar:2.2.0:compile
      |  +- commons-dbcp:commons-dbcp:jar:1.2.2:compile
      |  |  \- commons-pool:commons-pool:jar:1.3:compile
      |  +- org.directwebremoting:dwr:jar:2.0.1:compile
      |  +- javax.servlet:jstl:jar:1.1.2:compile
      |  +- taglibs:standard:jar:1.1.2:compile
      |  +- opensymphony:oscache:jar:2.3:compile
      |  +- opensymphony:sitemesh:jar:2.2.1:compile
      |  +- org.tuckey:urlrewritefilter:jar:3.0.4:compile
      |  \- commons-lang:commons-lang:jar:2.4:compile

    So, we need to make sure that these are available. This can be done by changing the packagingExclude of WEB-INF/lib/* to not exclude everything, but rather exclude everything except what we want to keep.

    This can be done in this way:

          <packagingExcludes>
       %regex[WEB-INF/lib/(?!clickstream|struts|appfuse|commons-fileupload|commons-dbcp|dwr|oscache|sitemesh|urlrewritefilter|commons-lang|velocity|xwork|commons-digester).*.jar]
      </packagingExcludes>

    This will make glassfish stop complaining about classes not being found. I’m not quite there yet, so might need to include some more jars, but it’s getting closer.

    • 0