The "war" task's "webxml" attrib is no longer able to use a value with a starting backslash for the path in Windows. For example, if the "webxml" attrib value is specified as "\test\web.xml", in previous releases (before v1.5.2 [like v1.5Beta]), the "war" task was able to interpret this as meaning that the "web.xml" file located in the "test" directory of the project's base drive should be used. With the latest nightly build (and v1.5.2), the "war" task ignores the previous example "webxml" attrib. (Note that other attribs of the "war" task like "destfile", "basedir", etc. are able to handle correctly values that start with "\". Perhaps this is due to the fact that the "war" file subclasses the "zip" task.)
Are you sure it gets ignored? How do you check the resulting war archive? WinZIP? Does your web.xml show up if you run "jar tf" against the war file? If you answer yes to the last two questions, please mark this bug as a duplicate of bug 17648.
I verified that it gets ignored. I used both UnZip 5.41 and jar (JDK1.4.1_02) [both on Windows]. (Besides, when the "war" task runs, it just so happens that there is a "WEB- INF/web.xml" file in the selected war files of the task, so the task displays "[war] Warning: selected war files include a WEB-INF/web.xml which will be ignored (please use webxml attribute to war task)" when the "webxml" attrib of the task has something like "\Xxx\Yyy\Zzz.xml" -- presumably because the task was not able to find "\Xxx\Yyy\Zzz.xml" to use as the "web.xml" file; but when the "webxml" attrib is "D:\Xxx\Yyy\Zzz.xml", then all is well. Keep in mind that Ant is invoked on the Windows command line at the "D:" drive, the build file is also located on the "D:" drive, and all the files that the task uses are also on the "D:" drive.) So I believe that this issue is NOT a duplicate of bug 17648.
Hmm, the main change is that the webxml attribute now uses <fileset>'s file attribute internally. I don't have Windows around, could you please try this snippet and port the result? <path id="foo"> <fileset file="\Xxx\Yyy\Zzz.xml"/> </path> <property name="foo-as-prop" refid="foo"/> <echo>${foo-as-prop}</echo> and compare it to <path id="foo"> <fileset file="D:\Xxx\Yyy\Zzz.xml"/> </path> <property name="foo-as-prop" refid="foo"/> <echo>${foo-as-prop}</echo> they are supposed to echo the same file name.
For the following "test" task: -------- <target name="test"> <antcall target="test1" /> <antcall target="test2" /> <antcall target="test3" /> <antcall target="test4" /> </target> <target name="test1"> <path id="foo"> <fileset file="\Xxx\Yyy\Zzz.xml"/> </path> <property name="foo-as-prop" refid="foo"/> <echo>${foo-as-prop}</echo> </target> <target name="test2"> <path id="foo"> <fileset file="D:\Xxx\Yyy\Zzz.xml"/> </path> <property name="foo-as-prop" refid="foo"/> <echo>${foo-as-prop}</echo> </target> <target name="test3"> <war destfile="\test3.war" webxml="\Xxx\Yyy\Zzz.xml"> </war> </target> <target name="test4"> <war destfile="\test4.war" webxml="D:\Xxx\Yyy\Zzz.xml"> </war> </target> -------- Here is the output: -------- Buildfile: D:\Stoehr\cincro\src\build.xml test: test1: [echo] D:\Xxx\Yyy\Zzz.xml test2: [echo] D:\Xxx\Yyy\Zzz.xml test3: [war] Building war: D:\test3.war [war] Warning: selected war files include a WEB-INF/web.xml which will be ignored (please use webxml attribute to war task) test4: [war] Building war: D:\test4.war BUILD SUCCESSFUL Total time: 1 second --------
One clarification about the "test3" and "test4" tasks are that there are no files to be included in the war file except for the "web.xml" file. So it is weird to get the "war" warning for the "test3" task. Also note that in both cases, the "destfile" attrib of the "war" task does not include the drive -- yet the "war" task was able to output both war files at the correct location.
I can confirm the existence of this bug. I have done a test of this bug under Win2000 and JDK 1.4.1_01-b01 I think I also have found the origin of this bug : 1)War.java#zipFile(File file, ZipOutputStream zOut, String vPath, int mode) contains a line saying ... !deploymentDescriptor.equals(file) ... in test3 deploymentDescriptor = \Xxx\Yyy\Zzz.xml file = D:\Xxx\Yyy\Zzz.xml therefore War.java#zipFile refuses to include \Xxx\Yyy\Zzz.xml into the war file 2) AbstractFileSet.java does this public void setFile(File file) { ... setDir(fileUtils.getParentFile(file)); ... } getParentFile returns D:\Xxx\Yyy\ always, independently of whether file contains the drive specification or not
Created attachment 5298 [details] fixes the problem in War.java
Hmm, I see. I don't think using the canonical path is the correct solution (we'll technically the solution is correct, but probably not in terms of how it should be addressed in Ant). deploymentDescriptor should probably get the drive letter added to it in the first place - I'll look into it.
Could you please either try the next nightly build (i.e. 2003-03-14) or replace the 1.5.2 ant.jar with the one from <http://cvs.apache.org/~bodewig/ant.jar> and see whether it fixes the problem?
After deleting the "test?.war" files and re-running the "test" target with the http://cvs.apache.org/~bodewig/ant.jar JAR, it now appears that the "test3.war" file is generated with the appropriate "web.xml" file within it. Thanks!
Thanks.