ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: [VOTE] Porting <fileset> 'file' attribute to 1.5 branch
Date Mon, 02 Sep 2002 15:49:38 GMT

If you add the file attribute to the AbstractFileSet class I suppose that it
will be available for both the <fileset> and <dirset> tasks, right?  In that
case the attribute name is maybe somewhat unfortunate.  E.g.

	<dirset file="somedir"/>

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.

	<fileset file="foo.txt,bar.txt"/>

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 <fileset>.",
right?  Maybe the setFile(File) method should check the file, or at least
its parent directory for existence.



> -----Original Message-----
> From: Erik Hatcher []
> Sent: Montag, 2. September 2002 10:41
> To: ant-dev
> Subject: [VOTE] Porting <fileset> '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: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message