Maven 2.x WAR Plugin

Transitive dependencies of optional dependencies are included in WEB-INF/lib

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0.2
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Maven 2.0.7, JDK 1.6.0_01-b06, JavaEE 5
  • Number of attachments :
    3

Description

I have an EAR project (TestEAR) which contains two modules:

1. A JAR module (TestJAR) which has one dependency: commons-lang 2.3
2. A WAR module (TestWAR) which uses these instructions to declare a dependency on TestJAR so that TestJAR is included in TestWAR's manifest classpath, but not copied into WEB-INF/lib (i.e. declares the dependency optional).

This works fine for TestJAR itself, but its transitive dependency (commons-lang 2.3) is still copied into WEB-INF/lib. I don't believe this is the correct behavior since all dependencies of a JAR packaged in the EAR must also be packaged in the EAR. So, all a WAR should have to do is put the transitive dependencies in its manifest classpath to inherit them. Basically: in a WAR, transitive dependencies of "optional" dependencies should inherit the "optional" flag.

I have included a simple test project as an example. Unzip, cd TestProject, and mvn install. Look in TestEAR's target dir and you will see that commons-lang is included in the EAR. Then look in TestWAR's target dir and you will see that commons-lang is also included in both the manifest classpath and the WEB-INF/lib dir.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MECLIPSE-360 Optional web app dependencies are not treated the same way as maven-ear-plugin

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MWAR-125 war manifest generation : optional=true not transitive

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MWAR-83 transitive dependency on POM artifact not respected

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Chris Lance added a comment -

This is a quick patch I put together against the trunk for this issue. Forgive my ignorance if there was an easier way to code it

Show
Chris Lance added a comment - This is a quick patch I put together against the trunk for this issue. Forgive my ignorance if there was an easier way to code it
Hide
Permalink
Keith Naas added a comment -

Here is a patch that does a full search of the project dependencies instead of just one level deep.

This is incredibly important for our company as we deploy ears, exclusively and if it scans through the entire dependency list to see if its optional, we can simply have one project control all of our common optional dependencies.

Show
Keith Naas added a comment - Here is a patch that does a full search of the project dependencies instead of just one level deep. This is incredibly important for our company as we deploy ears, exclusively and if it scans through the entire dependency list to see if its optional, we can simply have one project control all of our common optional dependencies.
Hide
Permalink
Antoni Reus added a comment -

Same problem here. As a workaround, you can put de de transitive dependencies in the exclusions list

Show
Antoni Reus added a comment - Same problem here. As a workaround, you can put de de transitive dependencies in the exclusions list
Hide
Permalink
Rich Taylor added a comment -

This is a serious issue for us as well. Each time we add a new dependency to our EAR, it is automatically put into our WAR module's WEB-INF/lib, leading to duplicate jars and classloading issues. It's very error prone to maintain a list of exclusions in the WAR's pom.

Show
Rich Taylor added a comment - This is a serious issue for us as well. Each time we add a new dependency to our EAR, it is automatically put into our WAR module's WEB-INF/lib, leading to duplicate jars and classloading issues. It's very error prone to maintain a list of exclusions in the WAR's pom.
Hide
Permalink
Adrian added a comment -

Same thing here, this correction would be usefull even in 2013 :

  • Eclipse m2e-wtp doesn't handle packagingExcludes with regex (as adviced by maven skinny wars instructions http://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html).
  • for pure Java EE 6 applicatins :
    Java EE 6 doesn't say anything on CDI classloading rules for EAR.
    For some appServers - i.e. JBoss 7.1, we need to package any archive containing CDI beans in EAR, never in war file otherwise we'll get AmiguousException when using n wars.
    So we'll need to :
    • package CDI bean archives in EAR.
    • JSF related archives in WARs (otherwise faces-config.xml are not loaded).

So we're stuck with using scope provided in war pom.xml for now if we want to use Eclipse and JBoss 7.1 with a Java EE 6 EAR.

Show
Adrian added a comment - Same thing here, this correction would be usefull even in 2013 : Eclipse m2e-wtp doesn't handle packagingExcludes with regex (as adviced by maven skinny wars instructions http://maven.apache.org/plugins/maven-war-plugin/examples/including-excluding-files-from-war.html ). for pure Java EE 6 applicatins : Java EE 6 doesn't say anything on CDI classloading rules for EAR. For some appServers - i.e. JBoss 7.1, we need to package any archive containing CDI beans in EAR, never in war file otherwise we'll get AmiguousException when using n wars. So we'll need to : package CDI bean archives in EAR. JSF related archives in WARs (otherwise faces-config.xml are not loaded). So we're stuck with using scope provided in war pom.xml for now if we want to use Eclipse and JBoss 7.1 with a Java EE 6 EAR.

People

  • Assignee:
    Unassigned
    Reporter:
    Chris Lance
Vote (32)
Watch (22)

Dates

  • Created:
    Updated: