Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-alpha-2
    • Fix Version/s: 2.1-beta-1
    • Component/s: None
    • Labels:
      None
    • Environment:
      RHEL 3
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      The <warSourceIncludes> element no longer seems to work, as of 2.1-alpha-2. It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will demonstrate the problem when used as follows:

      1) From the directory containing the pom.xml, create a web.xml, because otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
      mkdir -p src/main/webapp/WEB-INF
      touch src/main/webapp/WEB-INF/web.xml

      2) Build with the 2.1-alpha-1 plugin
      mvn clean install -Dwar.plugin.version=2.1-alpha-1

      3) Dump out the jar contents to verify that only commons-logging and the web.xml were packaged, as requested
      [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
      META-INF/
      META-INF/MANIFEST.MF
      WEB-INF/
      WEB-INF/web.xml
      WEB-INF/lib/
      WEB-INF/lib/commons-logging-1.1.jar
      META-INF/maven/
      META-INF/maven/example/
      META-INF/maven/example/example-war/
      META-INF/maven/example/example-war/pom.xml
      META-INF/maven/example/example-war/pom.properties

      4) Now build using the 2.1-alpha-2 plugin version:
      mvn clean install -Dwar.plugin.version=2.1-alpha-2

      5) Dump out the jar contents and notice that warSourceIncludes was ignored this time:
      [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
      META-INF/
      META-INF/MANIFEST.MF
      WEB-INF/
      WEB-INF/classes/
      WEB-INF/lib/
      WEB-INF/web.xml
      WEB-INF/lib/commons-logging-1.1.jar
      WEB-INF/lib/log4j-1.2.12.jar
      WEB-INF/lib/logkit-1.0.1.jar
      WEB-INF/lib/avalon-framework-4.1.3.jar
      WEB-INF/lib/servlet-api-2.3.jar
      META-INF/maven/
      META-INF/maven/example/
      META-INF/maven/example/example-war/
      META-INF/maven/example/example-war/pom.xml
      META-INF/maven/example/example-war/pom.properties

      1. pom.xml
        1 kB
        Bryan Loofbourrow

        Issue Links

          Activity

          Hide
          Bryan Loofbourrow added a comment - - edited

          Wonderful. Thank you Dennis, I look forward to testing out the new parameter. Feedback below:

          1) The new packagingIncludes example in the page you linked looks fine, and of course you are welcome to use my wording. The only thing that jars a bit (no pun intended) is that the use of a tag library as an example implies that it's a UI war, and likely you'd never get away with so short an includes list in a UI war. For example, here's what one of the UI wars I work with has, in addition to the jar includes:

          **/*.xml,**/*.properties,**/*.class,**/*.gif,**/*.png,**/*.jpg,**/*.css,**/*.js,**/*.html,**/*.tld,**/*.jsp,**/*.tag

          I'm not claiming that this matters enough to make it necessary to make a change in the example, just that it's worth pointing out to you.

          2) Another thing I should point out about that page, although I realize that the connection to packingIncludes is almost tangential. That last section starts off

          "Now the painful part. Your EAR project's <<<pom.xml>>> needs to list every dependency that the WAR has.
          This is because Maven assumes fat WARs and does not include transitive dependencies
          of WARs within the EAR."

          Enumerating transitive dependencies is sure painful, especially to maintain, – but it's not actually necessary, if one adopts the practice I mention in the comments on the skinny wars page I linked above – combining the dependencies that are not packaged in the war into a separate pom project, and having both the skinny war, and the ear, depend on them.

          3) I'm wondering about how the behavior change in warSourceIncludes will manifest to users who are not following the discussion. Is there any way that users of the old will know to start using the new, such as a failing build with an error message, or do they have to learn the hard way, by noticing the behavioral changes? I'm not worried for myself – my organization has wised up, pinned all plugin versions, and invoked the "loving iron fist of Maven" to enforce the pinning. So we'll be reading release notes and docs when we pick up a new version of a plugin. But the default behavior of Maven is to go get the latest released version of a plugin on a regular basis, and it strikes me that the behaviorial change to warSourceIncludes will silently slip into most builds. That's what happened to us with the behavioral change to warSourceExcludes from 2.1-alpha-1 to 2.1-alpha-2, and which led us to enforce plugin version pinning. I see that warSourceIncludes is merely changing behavior, not going away, which lets out the possibility of failing builds when someone tries to use it, but it would sure be nice if there was some sort of indication of the change for the default Maven case. Any thoughts about this?

          Show
          Bryan Loofbourrow added a comment - - edited Wonderful. Thank you Dennis, I look forward to testing out the new parameter. Feedback below: 1) The new packagingIncludes example in the page you linked looks fine, and of course you are welcome to use my wording. The only thing that jars a bit (no pun intended) is that the use of a tag library as an example implies that it's a UI war, and likely you'd never get away with so short an includes list in a UI war. For example, here's what one of the UI wars I work with has, in addition to the jar includes: **/*.xml,**/*.properties,**/*.class,**/*.gif,**/*.png,**/*.jpg,**/*.css,**/*.js,**/*.html,**/*.tld,**/*.jsp,**/*.tag I'm not claiming that this matters enough to make it necessary to make a change in the example, just that it's worth pointing out to you. 2) Another thing I should point out about that page, although I realize that the connection to packingIncludes is almost tangential. That last section starts off "Now the painful part. Your EAR project's <<<pom.xml>>> needs to list every dependency that the WAR has. This is because Maven assumes fat WARs and does not include transitive dependencies of WARs within the EAR." Enumerating transitive dependencies is sure painful, especially to maintain, – but it's not actually necessary, if one adopts the practice I mention in the comments on the skinny wars page I linked above – combining the dependencies that are not packaged in the war into a separate pom project, and having both the skinny war, and the ear, depend on them. 3) I'm wondering about how the behavior change in warSourceIncludes will manifest to users who are not following the discussion. Is there any way that users of the old will know to start using the new, such as a failing build with an error message, or do they have to learn the hard way, by noticing the behavioral changes? I'm not worried for myself – my organization has wised up, pinned all plugin versions, and invoked the "loving iron fist of Maven" to enforce the pinning. So we'll be reading release notes and docs when we pick up a new version of a plugin. But the default behavior of Maven is to go get the latest released version of a plugin on a regular basis, and it strikes me that the behaviorial change to warSourceIncludes will silently slip into most builds. That's what happened to us with the behavioral change to warSourceExcludes from 2.1-alpha-1 to 2.1-alpha-2, and which led us to enforce plugin version pinning. I see that warSourceIncludes is merely changing behavior, not going away, which lets out the possibility of failing builds when someone tries to use it, but it would sure be nice if there was some sort of indication of the change for the default Maven case. Any thoughts about this?
          Hide
          Dennis Lundberg added a comment -

          2.1-beta-1-SNAPSHOT deployed now.

          1) I changed the example by included some, but not all, of your includes.

          2) I added a link on the WAR Plugin's skinny wars page that goes to the wiki page you mentioned.

          3) Yes it's difficult to handle that, when it's not possible to deprecate the old/wrong parameter.

          Show
          Dennis Lundberg added a comment - 2.1-beta-1-SNAPSHOT deployed now. 1) I changed the example by included some, but not all, of your includes. 2) I added a link on the WAR Plugin's skinny wars page that goes to the wiki page you mentioned. 3) Yes it's difficult to handle that, when it's not possible to deprecate the old/wrong parameter.
          Hide
          Kaja Kvinge Akselsen added a comment -

          I am thrilled to see that there has been submitted a patch for this, as we have the exact same problem. I've tried out the new patch, but when I package the war all of the java classes, css and xmi files are missing. This is my plugin configuration:

          <plugin>
          <artifactId>maven-war-plugin</artifactId>
          <configuration>
          <packagingIncludes>WEB-INF/lib/junit*.jar</packagingIncludes>
          <archive>
          <manifest>
          <addClasspath>true</addClasspath>
          <classpathPrefix></classpathPrefix>
          </manifest>
          </archive>
          </configuration>
          </plugin>

          These are the files included in the war:

          Manifest.mf
          pom.properties
          pom.xml
          web.xml
          junit-3.8.1.jar
          junitee-1.11.jar

          Show
          Kaja Kvinge Akselsen added a comment - I am thrilled to see that there has been submitted a patch for this, as we have the exact same problem. I've tried out the new patch, but when I package the war all of the java classes, css and xmi files are missing. This is my plugin configuration: <plugin> <artifactId>maven-war-plugin</artifactId> <configuration> <packagingIncludes>WEB-INF/lib/junit*.jar</packagingIncludes> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix></classpathPrefix> </manifest> </archive> </configuration> </plugin> These are the files included in the war: Manifest.mf pom.properties pom.xml web.xml junit-3.8.1.jar junitee-1.11.jar
          Hide
          Bryan Loofbourrow added a comment - - edited

          Re: comment just above: You need to add some more things to your packagingIncludes to tell the plugin to package those things in the war. Try:

          <packagingIncludes>WEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css</packagingIncludes>

          This issue is discussed two comments above yours.

          Show
          Bryan Loofbourrow added a comment - - edited Re: comment just above: You need to add some more things to your packagingIncludes to tell the plugin to package those things in the war. Try: <packagingIncludes>WEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css</packagingIncludes> This issue is discussed two comments above yours.
          Hide
          Dennis Lundberg added a comment -

          Fixed in r744705 and r745193.

          Show
          Dennis Lundberg added a comment - Fixed in r744705 and r745193.

            People

            • Assignee:
              Dennis Lundberg
              Reporter:
              Bryan Loofbourrow
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: