DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17934 --- Additional Comments From [EMAIL PROTECTED] 2004-12-21 11:33 --- war is far older than the roundup attribute, so any change to its default value would break backwards compatibility. Existing build files would suddenly start to behave different after an upgrade of Ant. I don't think that anybody ever wants to set roundup to false in a development environment because of the Ant always updates my war even if nothing changes that would be the result. You can always use presetdef to change Ant's defaults: presetdef name=mywar war roundup=true/ /presetdef will give you a mywar task that behaves the way you want. If you are willing to live with a Trying to override old definition of task war warning, you can even use presetdef name=war war roundup=true/ /presetdef -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17934 --- Additional Comments From [EMAIL PROTECTED] 2004-12-20 16:17 --- I think roundUp=false should the default for the war target, since this is likely to be needed for precompiled JSPs. true can remain the default for the zip and jar targets. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|1.7 |1.6.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.7 --- Additional Comments From [EMAIL PROTECTED] 2004-02-27 14:18 --- I've added a new roundup attribute that can be used to control the rounding behavior. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 21:55 --- hi all, - with Bea's weblogic 5.1 the current behaviour of ant's Zip-Task =1.5.2 is a bug - i migrated from an older ant-version to the 1.5.4stable, problem occurs in usage of ant's jar-task result was that after the complete deployment of packed webapps in war-achives an server-restart the weblogic-server recompiles every (!) JSP in production-environment. (of course there is for performance reason every recompilation turned off) before live-going of our new deployed version i had to fall back in org/apache/tools/ant/taskdefs/Zip.java form the ...lastModified() + 1999 to the ...lastModified() version. ** File-Date Manipulation in this hidden way isn't a good way. ** zip is a zip task and should zip files, nothing else. if you want to change the webapp deployment behaviour, then any additional task parameter should be implemented, but not the core-zip-behaviour. --- some more detailled explanation how weblogic handle jsp-compile-times. 1. Bea-Guys compile with theire jspc and generate a timestamp in every generated java-class derived from jsp's original timestamp. Original timestamp was e.g. 2000-01-01 10:01 and that they pack into the generated java-file as java.lang.long in milliseconds (!) 2. at server runtime they check the jsp-file-time in the war-file they compare e.g. 2000-01-01 10:02 (time of the jsp in the archive after running ant's jar task) with the original date (packed in the class at JSP's compile time) and find that 2000-01-01 10:02(JSP-in-warfile-time) is YOUNGER than 2000-01-01 10:01 (original JSP-time) and so the server decides to recompile every JSP one time after deployment. (That is not acceptable in production environment, precompilation of JSPs is here the right way.) 3. ant 1.5.2 The old zip-behaviour (ant's jar extends zip) created the JSP in above example with date 2000-01-01 10:00. And weblogic StaleIndicator now compares: 2000-01-01 10:00 Jsp-in-warfile-time) is OLDER than 2000-01-01 10:00 (original JSP-time). --- Weblogic's JSP-check is crazy, but acceptable. A zip-task should not manipulate lastModified. I think, this is a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-09-22 14:36 --- *** Bug 23327 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries --- Additional Comments From [EMAIL PROTECTED] 2003-04-18 01:15 --- In my book the impact of this bug cannot be overstated: it has cost us hours and hours of developer and QA productivity. Let me say that again, for emphasis: this bug has cost us hours and hours of developer and QA productivity. Every single time we deploy a new WAR, the application servers rebuild the JSP files, either on server startup or page access, depending on the configuration. Multiply this by a dozen people doing dozens of deployments a day, and then think about whether this should be an 'enhancement request' or 'bug'.
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 08:47 --- From the manual of the zip task: Please note that ZIP files store file modification times with a granularity of two seconds. If a file is less than two seconds newer than the entry in the archive, Ant will not consider it newer. If Ant was rounding down instead of up, it would always consider the files inside the archive out-of-date and thus always update your archive. I'm changing this to an enhancement request. The possible enhancement I see is a new attribute to control the rounding behavior, but for the reason above, rounding up has to be the default.
