You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Bryan Loofbourrow (JIRA)" <ji...@codehaus.org> on 2009/02/15 20:03:19 UTC
[jira] Issue Comment Edited: (MWAR-182) warSourceIncludes no longer
works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165710#action_165710 ]
Bryan Loofbourrow edited comment on MWAR-182 at 2/15/09 1:02 PM:
-----------------------------------------------------------------
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:
{noformat}**/*.xml,**/*.properties,**/*.class,**/*.gif,**/*.png,**/*.jpg,**/*.css,**/*.js,**/*.html,**/*.tld,**/*.jsp,**/*.tag{noformat}
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?
was (Author: bryanloof):
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?
> warSourceIncludes no longer works
> ---------------------------------
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
> Issue Type: Bug
> Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
> Reporter: Bryan Loofbourrow
> Attachments: pom.xml
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira