You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by James Bucanek <su...@gloaming.com> on 2001/06/07 00:50:36 UTC
A few suggestions
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
<ma...@gloaming.com>
Re: A few suggestions
Posted by Peter Donald <do...@apache.org>.
At 09:47 PM 6/6/01 -0700, James Bucanek wrote:
>>>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.
>>
>>right - I wanted to extend mappers to do this sort of thing but it was
>>-1'ed ;)
>
>Well I suppose it depends on how you did it, but I'd probably would
>have -1'd it too. :(
>
>I think filters (aka "cullers") perform a separate function from
>mappers. For one, you'd have the flexibility of being able to
>specify cullers and mappers in arbitrary combinations. And, cullers
>would could apply to single (source file list) task contexts whereas
>mappers logically imply a target file for each source file.
I am not sure I agree. In my mind mappers, map an attribute of input item
to an attribute of output item(s). Currently we restrict that to just one
attribute (name) but "culler" functionality is a generalization to multiple
attributes (read-access, modify-time, etc).
BTW currently mappers can map many-to-1 and 1-to-many (or none) so I am not
sure "mappers logically imply a target file for each source file" is
completely accurate ;) It would be more accurate to say "mappers logically
imply zero or more target names for each input name".
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: A few suggestions
Posted by James Bucanek <su...@gloaming.com>.
At 12:07 PM +1000 6/7/01, Peter Donald wrote:
>At 03:50 PM 6/6/01 -0700, James Bucanek wrote:
>>(1) Conditionals. ant needs a vastly more flexible conditional
>>structure than just if=/unless= a property is/not defined.
>
>Condition will most likely test for presence and if present whether it
>evaluates to false or not. The evaluation of complex (less than, not etc)
>will probably relegated to another task.
If conditions would test by value (true/false), then I think we'd be
90% there. It would not be as nice as having expression evaluation
everywhere. But if a task could evaluate an expression and then set
a property with the result, ant would at least have the functionality
I mentioned, if not the brevity.
>
>>(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)?
>
>Yep - we will be doing this ... somehow. The *how* part has yet to be
>determined though.
>
>>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.
>
>right - I wanted to extend mappers to do this sort of thing but it was
>-1'ed ;)
Well I suppose it depends on how you did it, but I'd probably would
have -1'd it too. :(
I think filters (aka "cullers") perform a separate function from
mappers. For one, you'd have the flexibility of being able to
specify cullers and mappers in arbitrary combinations. And, cullers
would could apply to single (source file list) task contexts whereas
mappers logically imply a target file for each source file.
__________________________________
James Bucanek
<ma...@gloaming.com>
Re: A few suggestions
Posted by Peter Donald <do...@apache.org>.
At 03:50 PM 6/6/01 -0700, James Bucanek wrote:
>(1) Conditionals. ant needs a vastly more flexible conditional
>structure than just if=/unless= a property is/not defined.
Condition will most likely test for presence and if present whether it
evaluates to false or not. The evaluation of complex (less than, not etc)
will probably relegated to another task.
>(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)?
Yep - we will be doing this ... somehow. The *how* part has yet to be
determined though.
>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.
right - I wanted to extend mappers to do this sort of thing but it was
-1'ed ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: A few suggestions
Posted by Diane Holt <ho...@yahoo.com>.
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 <su...@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
> <ma...@gloaming.com>
>
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/