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 7242] - Please expand definition and implementation of Pattern
Date Fri, 08 Nov 2002 13:49:32 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=7242>.
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=7242

Please expand definition and implementation of Pattern





------- Additional Comments From simon.spruzen@rbos.com  2002-11-08 13:49 -------
But this works:

<patternset id="source.files"
                includes="*.cmd,*.sh,*.xml,*.template,*.pl"/>

In fact every task that takes an includes attribute allows for multiple 
filespecs separated by commas; this works well, so why should the <include> 
element for patternsets be special? Under this argument what about filenames 
that have '$' in them? You'd have to escape that in ant so ant doesn't try 
property expansion on it.

What I'm after is for patternsets to have the usefulness of if/unless 
processing + the flexibility of comma separated files.

In my example (below/above??) ejb.resource.include.files might be defined by 
the developer (in another buildfile) as a single file, or a list of files. 
Under your scheme, I'd have to encode it as:

<include name="${ejb.resource.include.file1}" if="ejb.resource.include.file1"/>
<include name="${ejb.resource.include.file2}" if="ejb.resource.include.file2"/>
<include name="${ejb.resource.include.file3}" if="ejb.resource.include.file3"/>
<include name="${ejb.resource.include.file4}" if="ejb.resource.include.file4"/>
<include name="${ejb.resource.include.file5}" if="ejb.resource.include.file5"/>
<include name="${ejb.resource.include.file6}" if="ejb.resource.include.file6"/>
...and so on...

I still believe this enhancement would be useful, that it would remove an ant 
oddity, and have attempted to post enough information to illustrate my point, 
but I don't wish to get into an argument. I guess we'll have to agree to differ 
on this one... :-)

simon.

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


Mime
View raw message