Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 57821 invoked from network); 14 Feb 2002 20:27:21 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Feb 2002 20:27:21 -0000 Received: (qmail 13930 invoked by uid 97); 14 Feb 2002 20:27:17 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 13913 invoked by uid 97); 14 Feb 2002 20:27:16 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 13901 invoked from network); 14 Feb 2002 20:27:16 -0000 Date: Thu, 14 Feb 2002 12:27:13 -0800 Subject: Re: Expanding a list of jars Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: Scott Ellsworth To: "Ant Users List" From: Scott Ellsworth In-Reply-To: <011b01c1b592$a91eb860$270610ac@manu.com> Message-Id: <3A96D6C5-2189-11D6-A945-0003931D19A4@alodar.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Thursday, February 14, 2002, at 12:03 PM, Magesh Umasankar wrote: > From: "Stefan Bodewig" >> On Fri, 8 Feb 2002, Scott Ellsworth wrote: >>> I have a multi stage build using ANT 1.4.1. Each stage produces a >>> jar containing the complete product of that stage. We want to >>> combine the results of several of those stages to build a final jar >>> for customer deployment containing everything in the various earlier >>> jars. >> >> Can help you here? I suspect the upcoming support will be a better fit when it comes, and I can live with my workaround until then. >> You've already seen that Ant's CVS version will have a way to help >> you, and it will probably even go further than that as soon as Brian >> Deitte's patches to Zip have made it into CVS (archive must have been >> down when he sent them, as I cannot find them). Basically, he adds a >> nested element that allows you to specify the sources for >> s as filesets, thus making obsolete. Any chance that we could add a "quiet" flag to it that would keep it from barfing if the fileset is empty? I can get around it either way, but it would be nice to have it elegant for my application. E.g. should work, as filesets are allowed to have empty things in them, IIRC. Will it fail silently if someone sends an empty fileset, and if not, is a flag to request that appropriate? Scott -- To unsubscribe, e-mail: For additional commands, e-mail: