The created war does not contain all files that are in the specified fileset, including files in the "root dir" and sub dirs. Interestingly, the verbose output shows one of the missing files identified as needed and added on a run that doesn't delete the war first: [war] [VERBOSE] perforcefaq.html added as perforcefaq.html is outdated. .... [war] [VERBOSE] adding entry perforcefaq.html Yet the resulting war does not have that file (and others). The war is large, around 360M; not sure if there are size limitations with the war. This is the snippet used to create the war: <war destfile="target/hm-ant-site.war" webxml="../../productname/main/web/WebContent/WEB-INF/web.xml"> <fileset dir="target/docs" /> </war>
This is pretty surprising. War is <jar>, and <jar> creates most JAR files in ant-enabled projects. Someone should have noticed. How did you test this? It wasnt with Winzip was it? What happens if you have a target like <target name="unzip" depends="war"> <mkdir dir="build/unzip" /> <unzip src="target.war" dest="build/unzip"/> </target> This will expand the entire war into a directory, and ensure that you are working with an unzip tool that we trust.
(In reply to comment #1) > This is pretty surprising. War is <jar>, and <jar> creates most JAR files in > ant-enabled projects. Someone should have noticed. I was very surprised too. It was working flawlessly for perhaps a year. The main thing that changed is big growth in file count. In defense of "noticed, I'm not sure how many people would have tested with a 360M war or jar file! :-) > How did you test this? It wasnt with Winzip was it? I first noticed it because of the missing files from the extracted war. The process creates the war and then pushes the war to Tomcat's webapps dir and Tomcat expands it. Voila, our dev site. Neatly done. But earlier this week the site was foo'd. Pages missing, display problems (e.g. a CSS file and icons missing). Easily noticed. I verified the files existed in the build area. Then I verified the war, and they were not there. So to directly answer your question: - tested via Tomcat expansion - tested via PowerArchiver opening - tested via jar -xf xx.war > What happens if you have a target like > > <target name="unzip" depends="war"> > <mkdir dir="build/unzip" /> > <unzip src="target.war" > dest="build/unzip"/> > </target> > > This will expand the entire war into a directory, and ensure that you are > working with an unzip tool that we trust. I think the jar tool covers it, but I will gladly test this on Monday (the machine is at my customer site) and report. Anything else to try, please just let me know!
ping, request for promised report
(thanks for the reminder :-) I created the war again (with the same snippet as listed in the description). Files were missing in it as viewed by PowerArchiver. I extracted the war to a new location with the same Ant snippet as Steve requested in comment 1. Files were there in the new location. Interesting that the Tomcat extract of the hot-deployed war was missing files. Perhaps there is some very very long time delay on extracts of it. Thanks for the help - I'm sure you will close this as Ant seems to perform fine.
(In reply to comment #4) > (thanks for the reminder :-) No problem. ;) > > I created the war again (with the same snippet as listed in the description). > Files were missing in it as viewed by PowerArchiver. > > I extracted the war to a new location with the same Ant snippet as Steve > requested in comment 1. Files were there in the new location. > > Interesting that the Tomcat extract of the hot-deployed war was missing files. > Perhaps there is some very very long time delay on extracts of it. > Thanks for the help - I'm sure you will close this as Ant seems to perform fine. > I think you just said this does appear to be no fault of Ant's. So, yes, we'll close it. If I misunderstood you in some way please reopen.