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=18166>. 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=18166 Concat enhancement ------- Additional Comments From [EMAIL PROTECTED] 2003-03-27 15:30 ------- >>but only sort-of as the parts in cat() only check for existance of the header >>and footer elements, not their value. But we are not doing any harm >> here after I've turned the printlns into prints. Which is why I said sort-of :) >>I still don't like the "cosmetic" trimleading attribute. ok... I can live without it, but would like to have it. I like my generated files and my build files to be readable. >>I still don't understand why filters get applied to nested text but not to >>header and footer. I'd like to see it consistent - and not applying filters >>to nested text either is the second option for consistency. They are used different purposes. The main (only) purpose I see for header and footer is to generate headers and footers for generated files. The header may be for example a copyright notice, a do not edit message, header include magic guards. The body of the generated file is a result of filtering multiple files. The requirements for these are quite different. The nested text of the concat I see as a replacement for the files in the body. (It also makes it easy to test filtering). To make things consistent, could a new attribute on textelement do the job (something like "preserve", "asis", "nofilter"). default to false, so that it is obvious when reading the build file that filtering will not take place. >>WRT reset. I'm not sure why it has been there in the first place, we cannot >>remove a public method. Making it work on the new attributes seems a good idea. On thinking about this, I think it may be there for <script/> to use in the dark old days of ant 1.2, but I may be wrong. >>WRT append semantics, you are right, it hasn't changed. But the name of the >>overwrite attribute is misleading (at least it has mislead me 8-). The >>combination of overwrite="yes" and append="true" does not overwrite the >>dest file. How about force instead of overwrite? <style> uses force as well. I realize this is misleading, but it is used by <copy>. It confused me there as well... force is fine for me. >> Let's resolve the filtering part and we are there 8-) magic!
