ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan.Mate...@rzf.fin-nrw.de
Subject AW: Issues with <modified /> selector.
Date Wed, 23 Jun 2004 11:18:06 GMT
I┬┤ll have a deeper look into that
(but now I have to ensure that my new computer is able to run - the old was
damaged :(


Jan


> -----Urspr├╝ngliche Nachricht-----
> Von: Robert Rice [mailto:robert@windermere.com]
> Gesendet am: Dienstag, 22. Juni 2004 20:23
> An: dev@ant.apache.org
> Betreff: Issues with <modified /> selector.
> 
> Recently, I submitted two bugs related to the modified selector.
> 
> Bug 29742 addresses the issue that the Modified selector 
> doesn't allow 
> algorithm or comparator selection.  Only the default choices 
> of "digest" 
> and "equal" respectively are allowed.  
> 
> I have created a bug fix for the modified selector that 
> addresses this 
> issue. 
> In the bug fix, the algorithm and comparator initialization 
> logic has been
> changed to allow choosing away from default.
> 
> At the same time, 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> )
> 
> How do I submit such changes for evaluation and possible inclusion?
> 
> Bug 29743 addresses a bigger issue in that the modified 
> selector has poor 
> cachefile save performance.  The architecture of the selector 
> framework 
> dictates that the selector is notified of files, one at a 
> time, through 
> the isSelected method.  It is at this method call, that the cache 
> properties file is saved.  This properties file is saved every time a 
> file modification is found, possibly as many times as there 
> are files in 
> the fileset.  This leads to poor performance when process 
> large filesets 
> with multiple changes, in my case around 15000.
> 
> I would like to delay the saving of the file until we are 
> finished with 
> the fileset or finished with the selector.  It looks to me, like this 
> requires the addition of one of more methods to the selector 
> framework, 
> likely to BaseSelector. 
> 
> In the case of the modified selector, we may be able to get away with 
> knowing we are finished with the selector through some method 
> call like 
> "tearDown".  At this point, the modified selector could save its 
> properites file.
> 
> Another option is to add filesetListener type of behavior to 
> the BaseSelector.
> This would notify a selector when a fileset selection has started and 
> ended. With this option, the modified selector could save its 
> properties 
> file at the end of fileset selection.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message