ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Rice <rob...@windermere.com>
Subject Problems with <modified /> select, shameless self promotion
Date Tue, 29 Jun 2004 18:42:19 GMT
Upon recently working with the <modified /> selector, I noticed a couple 
of issues.

(1) A bug in the algorithm and comparator initialization logic disallows 
the user from choosing anything but the default choices.  The "digest" 
algorithm and the "equal" comparator will always be utilized. So, of 
example, there is no way to choose the "hashvalue" algorithm as 
advertised.

(2) The propertiesfile will be rewritten every time a modified file is 
found.  When working with large filesets that have many changes, in my case 15000, 
this leads to poor performance as the properties file is rewritten many 
times ( up to 15000 times in my case ).  As the propertiesfile cache gets 
larger and larger, the performance continues to degrade.

Have other users of the <modified /> selector come up against these 
constraints?

I submitted two bugs, 29742 and 29743 respectively.

Next I repaired the bugs and submitted patches.  The attachements to 
bug 29743 address all bugs and enhancements.  Here is a bit about the 
fixes.

(1) The revised ModifiedSelector now implements the BuildListener 
interface.  Upon configuration, it registers itself with the Project as a 
BuildListener.  The ModifiedSelector is notified of finished BuildEvents, 
like taskFinished, targetFinished and buildFinished.  Saving of the 
cachefile is now delayed until the next finished BuildEvent occurs, most 
likely, a taskFinished call.

(2) There is also a new attribute called "delayupdate".  It defaults to 
true to gain the new performance increase of delaying the save of the 
cachefile.  Setting the "delayupdate" attribute to false allows continual 
cachefile updates ( like the current ModifiedSelector ).

(3) The algorithm and comparator initialization logic has been
changed to allow choosing away from default.

(4) I have created another algorithm type, "checksum", that makes
use of the java.util.zip.Checksum interface.  It is chosen by setting the
alogrithm attribute to "checksum" ( <modified algorithm="checksum" /> ).  
This checksum allows the choice of CRC32 or Alder32, which utilize
java.util.zip.CRC32 and java.util.zip.Adler32 respectively.  This choice 
is made by setting the algorithm.algorithm parameter to "CRC" or "ADLER", 
with the default being "CRC" ( <modified algorithm="checksum"><param
name="algorithm.algorithm" value="ADLER" /></modified> )

Please take a minute and vote for these bugs, if you have been up against 
these same constraints and find the patches useful.

Thanks,
Robert Rice


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message