Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 92825 invoked from network); 9 Nov 2001 01:35:10 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 9 Nov 2001 01:35:10 -0000 Received: (qmail 17254 invoked by uid 97); 8 Nov 2001 22:21:40 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 17214 invoked by uid 97); 8 Nov 2001 22:21:39 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 17203 invoked from network); 8 Nov 2001 22:21:39 -0000 From: "Mark Dumas" To: "Ant Developers List" Subject: RE: [SUBMIT] Switches And Sections Date: Thu, 8 Nov 2001 17:22:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-reply-to: <3BEAE237.4090306@speaklink.com> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N well, java has released it's api for regular expressions, however, nothing works easier than a simple asterik. perhaps the regular expression bit could handle the "case" property i was talking about so that seems to be cleaner. with a few working examples, i think everybody would do fine. -----Original Message----- From: Peter Davis [mailto:peter@speaklink.com] Sent: Thursday, November 08, 2001 2:51 PM To: Ant Developers List Subject: Re: [SUBMIT] Switches And Sections I was thinking regular expressions instead of glob-style matching, but then glob has a much faster learning curve for most people. Which would you rather use? Also, I know that other Ant tasks use globbing; (without having looked too much at Ant's source) is there an API to do glob matching easily? Mark Dumas wrote: >Peter - Thanks for the props. I figured they would be of use to someone. > >To answer your question, I think the match property sounds excellent. >Please >make the mod. Bonus points, allow wildcard asteriks and add an additional >property called "case" that can be "true" or "false". This applies case >sensitivity to the match. The case property defaults to "false"... the >match property defaults to null, as both would be optional. Thus, when >match is not present, the switch just looks for the existence of the >property as it does now... > >Also, the section is pretty darn simple, but someone that likes reference >ids could make a mod to them so they could be called from other parts >of the build file. this would add more meat to the bone for sections. > >Thanks, > >Mark > > > >-----Original Message----- >From: Peter Davis [mailto:peter@speaklink.com] >Sent: Wednesday, November 07, 2001 6:27 PM >To: Ant Developers List >Subject: Re: [SUBMIT] Switches And Sections > > >(This is also my first post -- Hi!) I've been using ant for a while, >but it has been difficult to build truly "automated" build scripts >because of lack of a good conditional build facility. Sure, there is > or , but having to separate out >all the conditional sections into separate targets is a pain (not to >mention that it pollutes the list of available targets and prints out >all that extra "target: \n" lines on output). I have also seen and >experimented with other custom -type tasks, but most of them are >still ugly and rely on external targets. Scripts are always an option >too, but setting up the BSF environment just for the build is not an >option on many of my target machines. > >I just want to say, props to Mark on something that I will definitely be >using in my own scripts, since it is the most elegant solution I have >yet seen. I hope that this or something like it can be included in the >distribution in the future. > >Question to Mark: what would you think of something like this: > > > ... > > >which would execute when ${foo} => "xyz", instead of being restricted to >only testing for "true" or "false". That would greatly simplify >creation of something like a build configuration file, since I wouldn't >have to write a bunch of . I >would be happy to attempt to write a patch for you if you like (assuming >you like my idea at all :->). > >Thank you! > > >Mark Dumas wrote: > >>Hello, >> >>This is my first post so bear with me. I came up with a few custom Ant >>tasks/classes that have been very useful and I wanted to pass them along. >> >>A Switch is a task container that tests for a condition represented by a >>property. If the property value is "true", inner tasks are executed >>depending on if they are identified in the pass and fail list properties. >> >>This allows users to specify multiple switch conditions in a single target >>without the need for multiple, bulky targets. >> >>The end result is a psuedo IF-THEN-ELSE construct. >> >>Sections are very simple helpers to Switches although they can stand alone. >>The examples in the html files will explain it all I think. >> >>Please view the readme.txt file for more details. >> >>Thanks, >> >>-Mark Dumas >>dumasm@mindspring.com >> >> >>------------------------------------------------------------------------ >> >>-- >>To unsubscribe, e-mail: >>For additional commands, e-mail: >> > >-- >Furthermore, I believe bacon prevents hair loss. > >Peter Davis >Developer, Speaklink Inc. >peter@speaklink.com > > > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: > > > -- Furthermore, I believe bacon prevents hair loss. Peter Davis Developer, Speaklink Inc. peter@speaklink.com -- To unsubscribe, e-mail: For additional commands, e-mail: