Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 94811 invoked from network); 2 Sep 2002 15:50:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Sep 2002 15:50:00 -0000 Received: (qmail 7254 invoked by uid 97); 2 Sep 2002 15:50:19 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 7116 invoked by uid 97); 2 Sep 2002 15:50:18 -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 6993 invoked by uid 98); 2 Sep 2002 15:50:17 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <36E996B162DAD111B6AF0000F879AD1A76BF85@nts_par1.paranor.ch> From: "Wannheden, Knut" To: 'Ant Developers List' Subject: RE: [VOTE] Porting 'file' attribute to 1.5 branch Date: Mon, 2 Sep 2002 17:49:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25298.585EBF8A" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C25298.585EBF8A Content-Type: text/plain; charset="iso-8859-1" Hi, If you add the file attribute to the AbstractFileSet class I suppose that it will be available for both the and tasks, right? In that case the attribute name is maybe somewhat unfortunate. E.g. Maybe a more neutral attribute as "select" or "includes" would be a good idea. Although using "includes" could be confusing too... But that raises another question: Why not extend the concept to several files instead of a single file? E.g. Further (as I'm not familiar with the details of the IntrospectionHelper) I was wondering what happens if the value identifies a non-existant file. I suppose I will get a message like "No directory specified for .", right? Maybe the setFile(File) method should check the file, or at least its parent directory for existence. Cheers, -- knut > -----Original Message----- > From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com] > Sent: Montag, 2. September 2002 10:41 > To: ant-dev > Subject: [VOTE] Porting 'file' attribute to 1.5 branch > > > Contrary to what I've said before about making sure the external > interface of 1.5 does not change with bug fixes, I'd like to propose > that we port the addition of the file attribute on AbstractFileSet to > the 1.5 branch. This minor addition makes life so much > easier, and I'm > using this new attribute in all my builds now as well. > > Before this addition, to get a fileset containing only a single file > when that file is referred to by a property, you had to get a > pointer to > its parent directory somehow. With property immutability and the > possibility that someone could override whatever property you use for > the parent directory, its not that safe. > > I have two conflicting personal reasons for and against > adding this to 1.5. > > For: I'm going to be travelling around a bit soon speaking on > Ant/XDoclet and all my example builds are using the 'file' attribute > because its so much cleaner. It would be nice if the > attendees could be > up and running with my samples with a released build of Ant 1.5.x > (although I'll likely bundle my version of Ant with any samples I > provide just to be on the safe side for now). > > Against: My book does not document the 'file' attribute, of > course, and > that would take it a bit out of synch, although its all backwards > compatible and we can add that to our errata list. > > But the benefits to the Ant community outweigh any arguments against > adding it, IMO. > > So, here's my +1. > > Erik > > > -- > To unsubscribe, e-mail: For additional commands, e-mail: ------_=_NextPart_001_01C25298.585EBF8A--