[
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
