warSourceIncludes no longer works

Sorry, the line in step 4 should read:

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

Cut/paste error on my part.

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

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.

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

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.

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.

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?

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.

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

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.

Fixed in r744705 and r745193.