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] New: - Please expand definition and implementation of Pattern
Date Tue, 19 Mar 2002 13:28:10 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

           Summary: Please expand definition and implementation of Pattern
           Product: Ant
           Version: 1.4.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Core
        AssignedTo: ant-dev@jakarta.apache.org
        ReportedBy: simon.spruzen@rbos.com


Please can you expand the defintion (and implementation) of Pattern 
(http://jakarta.apache.org/ant/manual/dirtasks.html#patterns) to allow a 
pattern to use the comma operator to define a list of patterns. So:

x,y,z

is currently a list of 3 patterns: x, y, z. This works in some elements, but 
not others. But I'd like this to be a single pattern with 3 sub-patterns.

The result of the comma operator would be the concatenated list of applicable 
files with duplicates removed, so each sub-pattern could still use * and ** as 
required: *.jar,**/whatever/*.jar.

The list of files ought to be evaluated when (if) the pattern is first 
referenced in an active target, because previous targets may change the list of 
applicable files.

Why do I want this?

The Patternset includes attribute vs. the nested include element is confusing 
and limiting. Take this case:

<!-- case 1 -->
<patternset id="ejb.resource.files">
    <include name="${ejb.resource.include.files}" 
if="ejb.resource.include.files"/>
</patternset>

This silently breaks if the ejb.resource.include.files property needs to be 
defined as a list of files. Whereas:

<!-- case 2 -->
<patternset id="ejb.resource.files" includes="${ejb.resource.include.files}" />

just as silently does the right thing, but without the benefit of the 'if' 
attribute.

It's worse if ejb.resource.include.files isn't defined: case 1 becomes an empty 
pattern which will imply 'include everything' in FileSets; case 2 becomes an 
empty pattern which will include nothing due to the side effect of property 
name expansion on names of non-existant properties (they expand to themselves, 
rather than standard shell behaviour of expanding to nothing: "". I rely on 
this side effect in a number of places, so if you change this behaviour, you 
will break a lot of (my) scripts!). To be safe, case 1 might need to be 
rewritten as:

<!-- case 1a -->
<patternset id="ejb.resource.files">
    <include name="${ejb.resource.include.files}" 
if="ejb.resource.include.files"/>
    <include name="[NONE]" unless="ejb.resource.include.files"/>
</patternset>

so if ejb.resource.include.files isn't defined, the patternset contains the 
single name: "[NONE]", which won't tend to exist as a file.


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