http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1667
*** shadow/1667 Tue May 8 14:57:19 2001 --- shadow/1667.tmp.6923 Tue May 8 14:57:19 2001 *************** *** 0 **** --- 1,49 ---- + +============================================================================+ + | unjar task unjars again, not checking dependencies | + +----------------------------------------------------------------------------+ + | Bug #: 1667 Product: Ant | + | Status: NEW Version: 1.3 | + | Resolution: Platform: PC | + | Severity: Normal OS/Version: | + | Priority: Component: Core tasks | + +----------------------------------------------------------------------------+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + It seems that the "unjar" task does not check dependencies between + input and output files as other Ant tasks do. + + The main problem is that unjar always emits messages indicating that + the task is being performed. Also not a huge problem, this does disrupt + checking that your build file covers everything correctly. + + (I'm thinking of the case of a fully incremental chain of tasks, running + Ant once to make sure everything it built, running Ant a second time, and + scanning the output to confirm that no tasks ran the second time, to make + sure you've set the build file up correctly. Many tasks are incremental, + and would work in that mode, but unjar is not. It always writes an output + message.) + + + The specific symptoms are: + + In non-verbose mode, unjar reports its "Expanding xxx into yyy/" + message even if no files are out of date. + + In verbose mode, unjar lists each file from the Jar file even if + no files are out of date. + + The unjar task also overwrites any extracted files that were + modified since the previous extraction. It's not clear whether + this is intentional (re-extracting to make the timestamp on the + file match the timestamp in the Jar file) or simply a result of + not checking dependencies. + + (No, it probably wouldn't be common to modify files after extracting + them, but if other Ant tasks don't overwrite _newer_ files, unjar + shouldn't either unless it specifically intends to make the output + files (e.g., their timestamps) match what's in the Jar file.)
