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 14:15 ------- >>> * you completely ignore all <fileset>'s and so on if nested text is present. > I think this is the original behaviour of concat. - it throws a > buildexception. You are right. >>> * The trim attribute in TextElement should apply to nested text as well >>> (instead of unconditionally trimming it. > It only looks like it unconditionally trims it. Yep. >>> * We might need the sanitizeText logic for header and footer as well. > The line (if (value.trim().length() == 0) sort of does this. 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. I still don't like the "cosmetic" trimleading attribute. 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. 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. 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. Let's resolve the filtering part and we are there 8-)
