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 18166] - Concat enhancement
Date Thu, 27 Mar 2003 15:30:06 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=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 peter.reilly@corvil.com  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!

Mime
View raw message