Maven 2.x WAR Plugin

warSourceIncludes no longer works

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. XML File
    pom.xml
    03/Feb/09 12:02 PM
    1 kB
    Bryan Loofbourrow

Issue Links

is related to

Wish - General wishlist item MWAR-81 Request enhancement to pattern matching for packagingIncludes/packagingExcludes functionality (regular expressions?)

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • 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
Bryan Loofbourrow added a comment -

Sorry, the line in step 4 should read:

mvn clean install -Dwar.plugin.version=2.1-alpha-2

Cut/paste error on my part.

Show
Bryan Loofbourrow added a comment - Sorry, the line in step 4 should read: mvn clean install -Dwar.plugin.version=2.1-alpha-2 Cut/paste error on my part.
Hide
Permalink
Bryan Loofbourrow added a comment -

Second correction: the text refers to "<warSourceExcludes>" in the first line. That should be "<warSourceIncludes>"

Show
Bryan Loofbourrow added a comment - Second correction: the text refers to "<warSourceExcludes>" in the first line. That should be "<warSourceIncludes>"
Hide
Permalink
Dennis Lundberg added a comment -

The behavior of <warSourceIncludes> was deliberately changed between 2.1-alpha-1 and 2.1-alpha-2. From 2.1-alpha-2 onwards <warSourceIncludes> works only on the files in the <warSourceDirectory>.

To exclude files that are added during the packaging of the WAR you can use this:

<packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>

But there is no corresponding <packagingIncludes> parameter. Do you really need such a parameter?

Show
Dennis Lundberg added a comment - The behavior of <warSourceIncludes> was deliberately changed between 2.1-alpha-1 and 2.1-alpha-2. From 2.1-alpha-2 onwards <warSourceIncludes> works only on the files in the <warSourceDirectory>. To exclude files that are added during the packaging of the WAR you can use this: <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes> But there is no corresponding <packagingIncludes> parameter. Do you really need such a parameter?
Hide
Permalink
Bryan Loofbourrow added a comment -

Not only do I need it, I am using it in a large, multimodule project, and it is hard to know what would substitute for it. Not packagingExcludes. My need is to package a small, but nonempty, subset of the jars into the war. That's hard to do well, and impossible to do in a stable manner, using a specification that can only tell what to exclude.

The need to package a small, but nonempty, subset of jars into a war, comes from the longstanding "skinny war problem" ( http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem ). In making an ear of skinny wars, one wants to package all of the jars into the ear, with, in some cases, a short list of exceptions that must be packaged into the war in order to work properly (generally tag libraries, in my case).

There are few decent solutions to the "skinny war problem" as things stand in Maven. By removing this includes functionality from the war plugin, the team would be taking away what is, in the current state of things, by far the best one, in my opinion.

Show
Bryan Loofbourrow added a comment - Not only do I need it, I am using it in a large, multimodule project, and it is hard to know what would substitute for it. Not packagingExcludes. My need is to package a small, but nonempty, subset of the jars into the war. That's hard to do well, and impossible to do in a stable manner, using a specification that can only tell what to exclude. The need to package a small, but nonempty, subset of jars into a war, comes from the longstanding "skinny war problem" ( http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem ). In making an ear of skinny wars, one wants to package all of the jars into the ear, with, in some cases, a short list of exceptions that must be packaged into the war in order to work properly (generally tag libraries, in my case). There are few decent solutions to the "skinny war problem" as things stand in Maven. By removing this includes functionality from the war plugin, the team would be taking away what is, in the current state of things, by far the best one, in my opinion.
Hide
Permalink
Jason Pringle added a comment -

Agreed, adding a corresponding <packagingIncludes> parameter would allow precise control over what JARs should be packaged into an "almost skinny" WAR.

Show
Jason Pringle added a comment - Agreed, adding a corresponding <packagingIncludes> parameter would allow precise control over what JARs should be packaged into an "almost skinny" WAR.
Hide
Permalink
Dennis Lundberg added a comment -

OK, thanks for the feedback complete with use case and all. That always makes it easier to understand the issue at hand. I'll try to add a <packagingIncludes> parameter then.

Show
Dennis Lundberg added a comment - OK, thanks for the feedback complete with use case and all. That always makes it easier to understand the issue at hand. I'll try to add a <packagingIncludes> parameter then.
Hide
Permalink
Dennis Lundberg added a comment -

I have added a <packagingIncludes> parameter and will deploy a new 2.1-beta-1-SNAPSHOT shortly for you guys to test.

Documentation is still only in Subversion, but you can read it there:
http://svn.eu.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/site/apt/examples/skinny-wars.apt?revision=744705&view=markup

I took the liberty of using your comments to describe the use case in the docs. Hope I got it right.

Show
Dennis Lundberg added a comment - I have added a <packagingIncludes> parameter and will deploy a new 2.1-beta-1-SNAPSHOT shortly for you guys to test. Documentation is still only in Subversion, but you can read it there: http://svn.eu.apache.org/viewvc/maven/plugins/trunk/maven-war-plugin/src/site/apt/examples/skinny-wars.apt?revision=744705&view=markup I took the liberty of using your comments to describe the use case in the docs. Hope I got it right.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: