Return-Path: Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 56414 invoked from network); 14 Nov 2000 16:53:39 -0000 Received: from smtpmta4.i2.com (64.26.226.14) by locus.apache.org with SMTP; 14 Nov 2000 16:53:39 -0000 Received: from i2cambridge.i2.com ([10.72.2.2]) by smtpmta4.i2.com (Lotus Domino Release 5.0.4a) with ESMTP id 2000111410533671:636317 ; Tue, 14 Nov 2000 10:53:36 -0600 Subject: Re: Combining PatternSets with Path elements To: ant-user@jakarta.apache.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: From: Matt_Conway@i2.com Date: Tue, 14 Nov 2000 11:53:35 -0500 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on i2Cambridge/Servers/i2Tech(Release 5.0.5 |September 22, 2000) at 11/14/2000 11:53:36 AM, Itemize by SMTP Server on SMTPMTA4/i2Tech(Release 5.0.4a |July 24, 2000) at 11/14/2000 10:53:37 AM, Serialize by Router on SMTPMTA4/i2Tech(Release 5.0.4a |July 24, 2000) at 11/14/2000 10:53:39 AM, Serialize complete at 11/14/2000 10:53:39 AM Content-type: text/plain; charset=us-ascii X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N An alternative approach, would be some way to combine a path element with a pattern to produce a patternset. The new pattern would simply be each path concatenated with each pattern in the given arguments. This would be less complex as it doesn't complexify the already complex patternset feature. Maybe it would look something like this: Matt Stefan Bodewig To: ant-user@jakarta.apache.org Subject: Re: Combining PatternSets with Path elements 11/13/00 04:19 AM Please respond to ant-user Matt Conway wrote: > This is sortof what I want as well - to be able to re-use a > "generic" patternset with a more specific include pattern - > i.e. reapply the include pattern to all the existing pattern, so a > previous pattern like "com/foo/bar/+" would become > "com/foo/bar/*.class" in a statement like given below > > > > > > > > > > > This re-uses the patternset "packages" which is generic - by generic > I mean that it has a '+' in it which is taken to mean that the + > will get replaced with whatever you include when you reuse the > patternset. Obviously, there are more details to be worked out =) I can see the benefit of restricting include patterns, but I'm not sure how to tackle this. The include patterns are additive and I think they should remain additive. The same holds for exclude patterns. What you are asking for is a way to refine a generic patternset for different use cases, I wouldn't go and overload the meaning of include for something like this. ? I'm not sure I'd want to add something like this as one probably needs one for the opposite action as well (exclude this package and that package but (only|not) the .bar files in them). This is one of the points where one starts trading convenience for complexity. Stefan