[jira] Commented: (MWAR-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=166117#action_166117 ] Bryan Loofbourrow commented on MWAR-182: 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: packagingIncludesWEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css/packagingIncludes This issue is discussed two comments above yours. 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 Assignee: Dennis Lundberg Fix For: 2.1-beta-1 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
[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-tabpanelfocusedCommentId=166117#action_166117
]
Bryan Loofbourrow edited comment on MWAR-182 at 2/18/09 1:14 PM:
-
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:
{noformat}packagingIncludesWEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css/packagingIncludes{noformat}
This issue is discussed two comments above yours.
was (Author: bryanloof):
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:
packagingIncludesWEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css/packagingIncludes
This issue is discussed two comments above yours.
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
Assignee: Dennis Lundberg
Fix For: 2.1-beta-1
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
[jira] Commented: (MWAR-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165710#action_165710 ] Bryan Loofbourrow commented on MWAR-182: 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/
[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-tabpanelfocusedCommentId=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
[jira] Commented: (MWAR-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=165306#action_165306 ] Bryan Loofbourrow commented on MWAR-182: 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. 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
[jira] Commented: (MEAR-96) earSourceExcludes does not work for jar dependency filtering like warSourceExcludes / packagingExcludes for the maven-war-plugin
[ http://jira.codehaus.org/browse/MEAR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163742#action_163742 ] Bryan Loofbourrow commented on MEAR-96: --- Yep, same issue here, in version 2.3.1. Note that the earSourceExcludes value pasted above wouldn't exclude commons-logging, but the one in the attached pom.xml would. I figure that's part of what ScottH means by munged. I worked around the problem by specifying a bundleDir for the jar in some location other than the one that the container will add to its classpath. Ugly and wasteful, but effective. earSourceExcludes does not work for jar dependency filtering like warSourceExcludes / packagingExcludes for the maven-war-plugin Key: MEAR-96 URL: http://jira.codehaus.org/browse/MEAR-96 Project: Maven 2.x Ear Plugin Issue Type: Bug Environment: Windows XP SP3 Reporter: Scott Heaberlin Attachments: pom.xml The earSourceExcludes parameter of the EarMojo does not appear to have any effect on jar dependencies. Given the pom below, commons-logging.jar should be excluded from the resultant .ear archive but is not. The junit test for the ear mojo (test-project-014) uses earSourceExcludes but only with files that are in the earSourceDirectory. Similar functionality works for the maven-war-plugin (warSourceExcludes, which was renamed to packagingExcludes) so it was a little confusing to find that earSourceIncludes does not allow filtering in the same fashion. -- example pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdexample/groupId artifactIdexample-ear/artifactId packagingear/packaging nameexample-ear/name version0.1-SNAPSHOT/version description sample ear project demonstrating effectiveness of earSourceExcludes parameter of the maven-ear-plugin /description build plugins plugin artifactIdmaven-ear-plugin/artifactId version2.3.1/version configuration earSourceDirectorysrc/main/application/earSourceDirectory earSourceExcludes**/commons*/earSourceExcludes /configuration /plugin /plugins /build dependencies dependency groupIdorg.springframework/groupId artifactIdspring-core/artifactId version1.2.7/version /dependency /dependencies /project -- 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
[jira] Created: (MWAR-182) warSourceIncludes no longer works
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 warSourceExcludes 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-1 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
[jira] Commented: (MWAR-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163759#action_163759 ] Bryan Loofbourrow commented on MWAR-182: Sorry, the line in step 4 should read: mvn clean install -Dwar.plugin.version=2.1-alpha-2 Cut/paste error on my part. 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 warSourceExcludes 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-1 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
[jira] Commented: (MWAR-182) warSourceIncludes no longer works
[ http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163800#action_163800 ] Bryan Loofbourrow commented on MWAR-182: Second correction: the text refers to warSourceExcludes in the first line. That should be warSourceIncludes 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 warSourceExcludes 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-1 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
[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162238#action_162238 ] Bryan Loofbourrow commented on MEAR-85: --- Stephane, that sounds fine, assuming that the ear plugin has a nice unambiguous way to know that the build is targeting JEE5. The main point for me is that I'm even more eager to see a solution for this now than I was last May. Thanks for taking this up. ejb-client dependencies should be placed in defaultLibBundleDir --- Key: MEAR-85 URL: http://jira.codehaus.org/browse/MEAR-85 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: James Olsen Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. A workaround is to add an ejbClientModule entry to override the bundleDir: modules ejbClientModule groupId.../groupId artifactId.../artifactId bundleDirlib/bundleDir /ejbClientModule /modules -- 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
[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143993#action_143993 ] Bryan Loofbourrow commented on MEAR-85: --- | I could add a flag to copy ejbClient artifacts in the defaultLibBundleDir. I'll take the liberty of replying with respect to my use case, described in my earlier comment, even though your question was addressed to James Olsen. As long as the flag applied to all ejbClient artifacts to be packaged in the ear, including the ones pulled in by transitive dependencies, it sounds as though it would fully address the use case that I have. Your proposal of a flag is probably better than mine of a second Dir parameter, given that there is probably no need to ever specify a distinct destination directory for ejbClient artifacts. There's merely a need to piggyback on the destination directory already specified. ejb-client dependencies should be placed in defaultLibBundleDir --- Key: MEAR-85 URL: http://jira.codehaus.org/browse/MEAR-85 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: James Olsen Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. A workaround is to add an ejbClientModule entry to override the bundleDir: modules ejbClientModule groupId.../groupId artifactId.../artifactId bundleDirlib/bundleDir /ejbClientModule /modules -- 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
[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=144011#action_144011 ] Bryan Loofbourrow commented on MEAR-85: --- Yeah, it's a little awkward to name, isn't it? I'll put a word in for the don't fear verbosity if it's the simplest thing you can think of approach. In other words, I'd just call it ejbClientsToDefaultLibBundleDir or similar. ejb-client dependencies should be placed in defaultLibBundleDir --- Key: MEAR-85 URL: http://jira.codehaus.org/browse/MEAR-85 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: James Olsen Assignee: Stephane Nicoll Priority: Minor Fix For: 2.3.2 ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. A workaround is to add an ejbClientModule entry to override the bundleDir: modules ejbClientModule groupId.../groupId artifactId.../artifactId bundleDirlib/bundleDir /ejbClientModule /modules -- 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
[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133344#action_133344 ] Bryan Loofbourrow commented on MEAR-85: --- The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use defaultLibBundleDir, and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of Minor/Improvement. Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present. ejb-client dependencies should be placed in defaultLibBundleDir --- Key: MEAR-85 URL: http://jira.codehaus.org/browse/MEAR-85 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.1 Reporter: James Olsen Priority: Minor ejb-client jars should be placed in the defaultLibBundleDir when specified. They're just standard jar dependencies not J2EE artifacts so should be treated the same as other jars. They're currently being placed in the root directory. A workaround is to add an ejbClientModule entry to override the bundleDir: modules ejbClientModule groupId.../groupId artifactId.../artifactId bundleDirlib/bundleDir /ejbClientModule /modules -- 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
[jira] Issue Comment Edited: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=133344#action_133344 ] bryanloof edited comment on MEAR-85 at 5/2/08 10:38 AM: The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use defaultLibBundleDir, and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of Minor/Improvement. Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present. was (Author: bryanloof): The situation I have, simplified, looks like this: ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS ON ejb-project-2-client In the ear project, jars are supposed to go into APP-INF/lib. I use defaultLibBundleDir, and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general. As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options? If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of Minor/Improvement. Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious. Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present. ejb-client
[jira] Commented: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94291 ] Bryan Loofbourrow commented on MSITE-211: - Same problem here with 2.0-beta-5; 2.0-beta-4 works fine. Can't deploy site using site:deploy due to a ProxyHTTP error Key: MSITE-211 URL: http://jira.codehaus.org/browse/MSITE-211 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: linux ubuntu dapper drake Reporter: Elid OR Priority: Blocker When I execute the site deployment (with version that comes with maven 2.0.5) mvn site:deploy I got an error see log en debug mode below. This used to work correctly with maven version 2.04 (so maybe site plugin version 2.0-beta-4 : [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading site at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: Forbidden at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) ... 18 more Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: proxy error: Forbidden at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) ... 20 more [INFO] [INFO] Total time: 3 seconds [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 [INFO] Final Memory: 3M/7M [INFO] -- 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
[jira] Created: (MWAR-81) Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?)
Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?) Key: MWAR-81 URL: http://jira.codehaus.org/browse/MWAR-81 Project: Maven 2.x War Plugin Issue Type: Wish Environment: n/a Reporter: Bryan Loofbourrow Priority: Minor The Maven War Plugin currently permits choosing what files will wind up in the .war. It does this via two parameters, warSourceIncludes, and warSourceExcludes. The rule appears to be that the includes are computed, and a list of matches made, then that list is run against the excludes, and any matches taken out of the include list. The only wildcards that appear to be supported are *, **, and ?. That doesn't work well if you are packaging wars in ears, and therefore want to exclude all jars from the war, except for one or two that have to be in the war in order to run properly. Exclude all but foo.jar and bar.jar just doesn't translate well to here's your simple include template, here's your simple exclude template representation, at least with current wildcards. So this is a wish specifically for something to address the exclude all but x, y, and z need for war source includes/excludes, and a suggestion that it might be best to deprecate the warSourceIncludes/warSourceExcludes approach in favor of a single parameter that supports regular expressions instead. -- 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
