XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On Sun, 19 Dec 2004 22:20:47 -0800, Wolfgang Hoschek <whoschek AT lbl.gov> wrote:
> > On Thu, 16 Dec 2004 15:09:25 -0800, Wolfgang Hoschek
> > <whoschek AT lbl.gov> wrote:
> >>
> >> Here are the details. Note the funny use of the "delete" task and
> >> overwrite="true". This fixes a funny ant behaviour, where ant
> >> sometimes
> >> seems to be unable to figure out that a file has indeed changed,
> >> unfortunately forgetting to copy it.
> >
> > You could file a defect with ant's bugzilla, but I think it'd be filed
> > as invalid
> >
> > 1. <copy> compares dest to source timestamps, and unless you say
> > 'preservelastmodified=true' timestamps the dest to the copy time.
> >
> > 2. so all following copies wont work as the dest file is newer than
> > the source(s), unless you actually edit the source.
> >
> > 3. You can use the <different> selector in your fileset to compare
> > files for byte-for-byte difference; this is actually very fast if the
> > file sizes differ.
> 
> It seems that a "smart" copy task should look at both timestamp and
> file size, rather than just timestamp.
> But I guess this issue has come up for lots of independent users
> before, and presumably the ant guys have good reasons for why they
> don't check file size (e.g. backwards compatility). Any "fix" would
> probably mean it wouldn't work on older ant versions, and as such be of
> limited value.

yes, compat is one reason, the other is that if you have
filter-on-copy enabled, the dest file wont match the source. If you
use the right selector in your fileset with copy forced, you get the
semantics you want.

-steve