ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: Need feedback on intended SourceFileScanner change
Date Mon, 02 Dec 2002 00:38:18 GMT
Instead of having getLastModified in TargetObject, 

public boolean isDirtyWhenComparedWith(Object src);
or if the "WhenComparedWith" seems to be pedantic, 
public boolean isDirty(Object src); 

The FileTarget would compare using last modified
time stamps and if target file is older than
src file, this method would return false.

Other implementations of TargetObject may choose 
different mechanisms to perform the comparison before 
saying that the target object is dirty or not.

As far as naming goes, the Object part in TargetObject 
seems pedantic to me.  Since we have a already,
how about naming it Targetable instead?


----- Original Message ----- 
From: "Stefan Bodewig" <>
To: <>
Sent: Thursday, November 28, 2002 10:44 AM
Subject: Need feedback on intended SourceFileScanner change

> I'm looking in how to solve 10755 - jar update="true" doesn't update -
> in a most general way.
> What I've come up with is to define a very tiny abstraction interface
> TargetObject with three methods:  exists(), getLastModified() and
> getName().  Then I have a TargetFactory that creates TargetObjects
> when given a name.
> Finally I've modified SourceFileScanner to work on TargetObjects
> instead of Files where the old method signature of restrict will use a
> TargetFactory that wraps File instances in TargetObjects.
> This is all much less complicated than it sounds 8-)
> <> about 7Kb.  My mailer and
> ezmlm don't like each other when I send attachments.
> With this change things still work exactly as before, all tests pass.
> But this gives us a low level entry point to compare source files with
> ZipEntries or TarEntries or remote files or ...
> Things I'd like feedback on before I commit anything
> (1) TargetFactory is a bit clumsy in that it is a know-all
> implementation.  It may be better to use an AbstractFactory and give
> people a chance to plug in their own factories.  I'm not sure whether
> it is worth the effort, though.
> (2) Should the concept be extended to the source files as well, so you
> can compare ZipEntries with TarEntries?  I really don't want to extend
> this to a full VFS layer, just thinking.  This may be useful in the
> context of <zipfileset> where you probably really wanted to compare
> ZipEntries from the source set to ZipEntries of an existing archive.
> (3) Names ... as always.  Chosing the right name for a class is not my
> strength.
> Stefan
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message