ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <hol...@yahoo.com>
Subject Re: A few suggestions
Date Thu, 07 Jun 2001 00:41:48 GMT
I believe your first issue is being planned for as a <condition> task. I
think the second one will be addressed by the "fileset culler" that was
discussed on ant-dev (search the ant-dev archive for that one).

Diane

--- James Bucanek <subscriber@gloaming.com> wrote:
> Greetings,
> 
> I've working with ant 1.3 again.  Overall I've been very happy with 
> it, and it's proved to be a robust tool.  But there are a few times 
> (like today) where I am becoming really frustrated with it.
> 
> I've been browsing through the voting for ant 2.0 that's been going 
> on over the past month or so and I don't see any one mention two 
> features/capabilities that I feel are really lacking.  If these 
> issues *are* being address, then please accept my apologies for 
> dredging them up again.
> 
> -----
> 
> (1) Conditionals.  ant needs a vastly more flexible conditional 
> structure than just if=/unless= a property is/not defined.
> 
> At the very least, the if=/unless= attributes should be able to test 
> the value of a property, not just whether it exists or not.  This has 
> been the bane of my existence, since many of my build conditionals 
> are based on the values of environmental variables.  I've sort of 
> solved it with a task that can set property names based on the values 
> of other properties, but I consider this a hack.
> 
> Ideally, a general purposes expression evaluator should be added to 
> the core ant code so targets and tasks can evaluate arbitrary 
> conditional statements.  I would humbly suggest it support the 
> operators =, >, <, contains, beginsWith, endsWith, not, and, or, and 
> xor.  A regexp 'matches' operator would also be way cool, and could 
> replace a number of the aforementioned operators.
> 
> An <if> element within targets, coupled with expression evaluation, 
> would make for pretty flexible scripting.  I know this has been 
> discussed, so I won't belabor the point.
> 
> -----
> 
> (2) Filters.  <fileset>/<patterset> needs some kind of simple, 
> extendable, filtering mechanism.  Why can't they take, as a 
> attribute, an argument that resolves to a java.io.FilenameFilter 
> object (or an ant equivalent)?
> 
> On occasion, I've been writing my own mappers to preform filtering as 
> a side effect, but it's pretty ugly.  Especially since you can't 
> extend the mapper tag to include any additional information that a 
> filter might need to do it's job.
> 
> Filters that would be useful are (a) newer - include a file if it is 
> newer than some target, (b) exists - include the file if a companion 
> file exists, (c) contains - include the file if it contains 
> something.  I'm sure there are lots of others.
> 
> -----
> 
> I appreciate everyone's effort, and would be more than happy to 
> contribute.  It think ant's a great tool, and I've been able to 
> rewrite what used to be some phenomenally hairy shell scripts into 
> some reasonable (and fast) Java code.
> 
> James
> 
> __________________________________
> James Bucanek
> <mailto:privatereply@gloaming.com>
> 


=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Mime
View raw message