Maven
  1. Maven
  2. MNG-1991

Can't get transitive dependencies from a war pom when this war is added as a depdency of a project

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.2
    • Fix Version/s: None
    • Component/s: Dependencies
    • Labels:
      None

      Description

      I have a project (continuum-core-it) that need to use all transitive dependencies of a war (continuum-webapp). If i add the war as a dependency of the project with packaging war, war dependencies aren't shown by project, maven doesn't try to resolve them and doesn't add them in classpath.
      If if replace packaging from war to pom, all dependencies are resolved and added to classpath.

      1. war-deps.tar
        50 kB
        Shane StClair

        Issue Links

          Activity

          Hide
          Brett Porter added a comment -

          this is by design, since the war already includes its dependences. Why do you need them?

          Show
          Brett Porter added a comment - this is by design, since the war already includes its dependences. Why do you need them?
          Hide
          Emmanuel Venisse added a comment -

          I need dependencies of war because in continuum-core-it i use plexus.xml/components.xml of continuum-webapp, so some components decleare in them are in war dependencies and i don't want to add these deps in continuum-core-it pom.
          I'm satisfied to declare the packaging of continuum-webapp to pom in continuum-core-it, because the war doesn't must be in the classpath.
          I just view this pb with war dependency and personnaly, i prefer to use the pom packaging, so you can close this issue if you want

          Show
          Emmanuel Venisse added a comment - I need dependencies of war because in continuum-core-it i use plexus.xml/components.xml of continuum-webapp, so some components decleare in them are in war dependencies and i don't want to add these deps in continuum-core-it pom. I'm satisfied to declare the packaging of continuum-webapp to pom in continuum-core-it, because the war doesn't must be in the classpath. I just view this pb with war dependency and personnaly, i prefer to use the pom packaging, so you can close this issue if you want
          Hide
          Barrett Nuzum added a comment -

          EARs bundling multiple WARs have a need to be able to resolve and bundle transitive dependency to reduce overall WAR size. ("skinny WARs")

          Show
          Barrett Nuzum added a comment - EARs bundling multiple WARs have a need to be able to resolve and bundle transitive dependency to reduce overall WAR size. ("skinny WARs")
          Hide
          Stephane Nicoll added a comment -

          Brett, another use case: overlays.

          You have a dependency on a war that contains classes you need to compile your project. Adding the war as an overlay of the war project should be enough to resolve its classes (and maybe associated libs)

          Show
          Stephane Nicoll added a comment - Brett, another use case: overlays. You have a dependency on a war that contains classes you need to compile your project. Adding the war as an overlay of the war project should be enough to resolve its classes (and maybe associated libs)
          Hide
          Anders Sveen added a comment -

          We're packaging a standalone Jetty server in a zip with the assembly and appassembler plugin. This project has a dependency on two skinny war-projects, and thus need to resolve the transitive dependencies and include them in the zip.

          From issues I have seen this is reported as problems with both the war and ear plugin, but seems to be a broader issue on how to resolve dependencies when the type is war.

          Show
          Anders Sveen added a comment - We're packaging a standalone Jetty server in a zip with the assembly and appassembler plugin. This project has a dependency on two skinny war-projects, and thus need to resolve the transitive dependencies and include them in the zip. From issues I have seen this is reported as problems with both the war and ear plugin, but seems to be a broader issue on how to resolve dependencies when the type is war.
          Hide
          Anders Sveen added a comment -

          Duplicating the dependency, just as a type=pom made the appassembler include the needed libraries. It's not the best way to do it, but might be an acceptable way for my use case.

          Show
          Anders Sveen added a comment - Duplicating the dependency, just as a type=pom made the appassembler include the needed libraries. It's not the best way to do it, but might be an acceptable way for my use case.
          Hide
          Brent N Atkinson added a comment -

          I believe the J2EE/JavaEE specifications designate packaging to an 'assembler' role for good reason. The code for web module and resource adapters (a real connector, not simply a configured JDBC pool) are managed well as plain jars. Dependencies are satisfied by external jars, and you have fine grained control over reuse. IMHO, making wars, rars, and ears first-class maven citizens seems a bit strange. The way you package them changes on the environment, Appserver, et cetera. The compiled code doesn't change.

          I have used the rar, ear and war plugins to build both skinny and full-fledged components. I can appreciate why you would want to package the full fledged components (at least war and rar) because they are reusable components much like the jar. They are intended to be boxed up and reused. However, these components imply configuration and repackaging (Class-Path entries in the manifests of modules, moving jars to ear-level, changing init-params, configuring security, adding appserver specific descriptors, etc). This seems to indicate that they are not artifacts in the traditional maven sense. They are not static like jars, so storing them as such doesn't make much sense. It may not make sense to store them with the jar dependencies bundled; this is like storing uberjars all over the place. Perhaps the realization of an war/ear with dependencies is better deferred?

          Wars and rars are ideally treated as components. So it may make sense to store them with their external dependencies. However, I believe dependency meta data could be used. This would perhaps be something like a dependency scope 'aggregate'? It would imply that transitivity blocks at the artifact that aggregates them. Unfortunately, if dependency meta data isn't available to dependent artifacts you can no longer identify or resolve conflicts, et cetera. If you could use this meta data, then you could perhaps control the ultimate fate of the dependencies through something like dependencyManagement. It may be enough information for an intelligent assembly plugin to realize the aggregate dependencies and patch up bundled modules with Class-Path manifest entries, et cetera.

          Show
          Brent N Atkinson added a comment - I believe the J2EE/JavaEE specifications designate packaging to an 'assembler' role for good reason. The code for web module and resource adapters (a real connector, not simply a configured JDBC pool) are managed well as plain jars. Dependencies are satisfied by external jars, and you have fine grained control over reuse. IMHO, making wars, rars, and ears first-class maven citizens seems a bit strange. The way you package them changes on the environment, Appserver, et cetera. The compiled code doesn't change. I have used the rar, ear and war plugins to build both skinny and full-fledged components. I can appreciate why you would want to package the full fledged components (at least war and rar) because they are reusable components much like the jar. They are intended to be boxed up and reused. However, these components imply configuration and repackaging (Class-Path entries in the manifests of modules, moving jars to ear-level, changing init-params, configuring security, adding appserver specific descriptors, etc). This seems to indicate that they are not artifacts in the traditional maven sense. They are not static like jars, so storing them as such doesn't make much sense. It may not make sense to store them with the jar dependencies bundled; this is like storing uberjars all over the place. Perhaps the realization of an war/ear with dependencies is better deferred? Wars and rars are ideally treated as components. So it may make sense to store them with their external dependencies. However, I believe dependency meta data could be used. This would perhaps be something like a dependency scope 'aggregate'? It would imply that transitivity blocks at the artifact that aggregates them. Unfortunately, if dependency meta data isn't available to dependent artifacts you can no longer identify or resolve conflicts, et cetera. If you could use this meta data, then you could perhaps control the ultimate fate of the dependencies through something like dependencyManagement. It may be enough information for an intelligent assembly plugin to realize the aggregate dependencies and patch up bundled modules with Class-Path manifest entries, et cetera.
          Hide
          Ian P. Springer added a comment -

          Note: The maven warpath plugin (http://static.appfuse.org/maven-warpath-plugin/) provides a workaround to this issue. I tried it out, and it worked nicely for me.

          Show
          Ian P. Springer added a comment - Note: The maven warpath plugin ( http://static.appfuse.org/maven-warpath-plugin/ ) provides a workaround to this issue. I tried it out, and it worked nicely for me.
          Hide
          Felix Simmendinger added a comment -

          we work with skinny wars a lot and we got use to declare also a dependency to the pom of the war. By doing this you get all dependencies resolved and retrieved to the WEB-INF/lib dir.

          Show
          Felix Simmendinger added a comment - we work with skinny wars a lot and we got use to declare also a dependency to the pom of the war. By doing this you get all dependencies resolved and retrieved to the WEB-INF/lib dir.
          Hide
          Maarten Billemont added a comment -

          I've created a separate issue for the overlay case, since the resolution for that will probably be different from resolving the skinny WAR use case, and shouldn't need any additional configuration. See MWAR-253

          Show
          Maarten Billemont added a comment - I've created a separate issue for the overlay case, since the resolution for that will probably be different from resolving the skinny WAR use case, and shouldn't need any additional configuration. See MWAR-253
          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
          Hide
          Jason van Zyl added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.
          Hide
          Shane StClair added a comment -

          Comment duplicated on MWAR-253, but example project is also relevant here so I'll cross-post.

          Example project attached (also at https://github.com/srstclair/war-deps) shows the current behavior, meaning that transitive dependencies of the war dependency are not available on the classpath (the war-deps-via-war module's tests fail). I agree that transitive dependencies should be resolved for war dependencies.

          Currently the best workaround I can come up with is to declare a second dependency on the war's pom, which does add transitive dependencies to the classpath (see war-deps-overlay). Is that the recommended approach?

          Show
          Shane StClair added a comment - Comment duplicated on MWAR-253 , but example project is also relevant here so I'll cross-post. Example project attached (also at https://github.com/srstclair/war-deps ) shows the current behavior, meaning that transitive dependencies of the war dependency are not available on the classpath (the war-deps-via-war module's tests fail). I agree that transitive dependencies should be resolved for war dependencies. Currently the best workaround I can come up with is to declare a second dependency on the war's pom, which does add transitive dependencies to the classpath (see war-deps-overlay). Is that the recommended approach?
          Hide
          Paul Benedict added a comment -

          Yes, that's how I have seen it done. You add the "war" to get the artifact and the war's "pom" to get its dependencies.

          Show
          Paul Benedict added a comment - Yes, that's how I have seen it done. You add the "war" to get the artifact and the war's "pom" to get its dependencies.
          Hide
          Miroslav Zaťko added a comment -

          transitive dependencies still not resolved by maven-ear-plugin

          Show
          Miroslav Zaťko added a comment - transitive dependencies still not resolved by maven-ear-plugin

            People

            • Assignee:
              Unassigned
              Reporter:
              Emmanuel Venisse
            • Votes:
              28 Vote for this issue
              Watchers:
              22 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development