Uploaded image for project: 'ShrinkWrap Resolvers'
  1. ShrinkWrap Resolvers
  2. SHRINKRES-263

Shrinkwrap resolver does not honor war dependencies

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5
    • Fix Version/s: 3.0.0-alpha-3, 2.2.6
    • Component/s: maven
    • Labels:
      None
    • Steps to Reproduce:
      Hide

      Test setup:
      A WAR project, with a beans.xml resource located at src/main/resources/META-INF/beans.xml

      Current behaviour:
      Shrinkwrap will build a .war file with the contents of ../target/classes, so the beans.xml is added as META-INF/beans.xml inside the .war. This is the wrong location.

      Correct behaviour:
      Shrinkwrap should look for a ../target/$project.artifactId-$project.version directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the beans.xml is added as WEB-INF/classes/META-INF/beans.xml.

      Show
      Test setup: A WAR project, with a beans.xml resource located at src/main/resources/META-INF/beans.xml Current behaviour: Shrinkwrap will build a .war file with the contents of ../target/classes , so the beans.xml is added as META-INF/beans.xml inside the .war. This is the wrong location. Correct behaviour: Shrinkwrap should look for a ../target/$project.artifactId-$project.version directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the beans.xml is added as WEB-INF/classes/META-INF/beans.xml .

      Description

      The class MavenResolvedArtifactImpl will try to resolve mvn artifacts. This works well since 2.2.5, for jar and test dependencies.

      For war dependencies this is still problematic though. The code looks like this:

      // SHRINKRES-102, allow test classes to be packaged as well
      File root = new File(artifact.getFile().getParentFile(), "target/classes");
      if (!Validate.isNullOrEmpty(classifier) && "tests".equals(classifier)) {
        root = new File(artifact.getFile().getParentFile(), "target/test-classes");
      }
      

      In other words, it will locate the pom, say foo/bar/pom.xml, and from there try to resolve ../target/classes or ../target/test-classes for tests.

      In case the pom has <packaging>war</packaging> this is not sufficient however. The Maven war plugin creates its output in ../target/$project.artifactId-$project.version.

      So if the Shrinkwrap resolver is used to resolve a .war, it will create a .war file with the wrong contents. This can be demonstrated for JavaEE with the beans.xml resource.

      Test setup:
      A WAR project, with a beans.xml resource located at src/main/resources/META-INF/beans.xml

      Current behaviour:
      Shrinkwrap will build a .war file with the contents of ../target/classes, so the beans.xml is added as META-INF/beans.xml inside the .war. This is the wrong location.

      Correct behaviour:
      Shrinkwrap should look for a ../target/$project.artifactId-$project.version directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the beans.xml is added as WEB-INF/classes/META-INF/beans.xml.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  florian.besser Florian Besser
                  Reporter:
                  florian.besser Florian Besser
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: