ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 26737] - Directory Scanner failure
Date Tue, 10 Feb 2004 15:27:52 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26737>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26737

Directory Scanner failure





------- Additional Comments From kovesp@sympatico.ca  2004-02-10 15:27 -------
<property name="prod.img.dir" location="${productionImage.dir}/
${release.ProductionImage}"/>

     <copy todir="${build.top.level}" preservelastmodified="yes">
         <fileset dir="${prod.img.dir}">
            <exclude name="DeliveredCode/**"/>
            <exclude name="HorizonCode/.project"/>
            <exclude name="HorizonCode/.classpath"/>
                <exclude name="HorizonCode/horizon16/build.xml"/>
            <exclude name="HorizonCode/horizon16/release.properties"/>
         </fileset>
      </copy>

release.ProductionImage was read from a "release.properties" file:

release.ProductionImage=2004_01_30_Production

and the developer inadvertently inserted a space at the end of the line so the 
value was "2004_01_30_Production ".

Normaly my build.xml checks all such items for validity, but I forgot to do 
this in this case. The copy task was executed with the above value resulting 
in the exception (the productionImage.dir had a valid value).

This is on "Apache Ant version 1.5.3 compiled on April 9 2003" and java 
version "1.3.1_08", however I checked the current 1.6 code base and it still 
contains the fragment I cited. I can't easily test this build.xml on 1.6 
because it uses some custom tasks of mine that are dependent of 1.5.3.

BTW: Mid-last year I put forward a proposal for adding a mapper to zipfilesets 
and selectors and a contentmapper to zipgroupfilesets (a contentmapper 
transforms names of zip entries as they are transferred from the input zips to 
the target zips). I implemented this as a custom task based on the core zip 
task (hence the incompatibility with anything but 1.5.3). 

I tried to offer this implementation for inclusion, but was totally unablae to 
elicit any response at all (not even go away, don't bother us...). Did I 
transgress etiquette in some way?

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


Mime
View raw message