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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> > ===== ([EMAIL PROTECTED]) __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
