I've taken the freedom to shuffle some parts of your answer to make it
easier for me to express my thoughts. Please forgive me.
>>>>> "sr" == rubys <[EMAIL PROTECTED]> writes:
>> This would mean that properties and taskdefs had to go into a
>> target probably named "init".
sr> And I don't want to reinvent "init".
Neither do I. Actually I didn't choose the name "init" by pure
coincidence.
BTW docs/index.html still says "It is good practice to place your
property [...] tasks in a so called initialization target" somewhere
below <h3>Targets</h3>. This is misleading.
sr> I feel that unifying all tasks would result in the simplest and
sr> easiest to understand system.
Right.
It might depend on what you define to be a task 8^). I will not
distinguish between property and taskdef on the one side and the rest
of the tasks on the other for a moment.
Unifying the tasks in a way that we forbid task to be outside of a
target will lead to "init" again. No thanks.
One thing I wouldn't want to lose is the clear Project -> Target ->
Task hierarchy Ant uses. So allowing all tasks to be placed anywhere
doesn't really look like an option to me either.
Do you see a way out?
Apart from that: Put together all tasks that have been placed outside
of targets, they form some kind of implicit "init". Granted, this time
this special meaning is visible from the build.xml.
sr> What actually happened was that a number of people objected to
sr> the special meaning associated with the "init" task.
sr> It is this behaving differently that causes confusion.
property, taskdef, available and tstamp (which is only a special
version of property to me) never behaved like the other tasks - as far
as I can tell.
It should be no problem to move available to the current task behavior
as long as (1) the property set by it isn't used in ${} substitutions
or (2) ${} happens at the time the task in question gets executed or
(3) ${} dies dies dies - I'm all with .duncan on this.
sr> And to the people who want to compile their taskdefs as part of
sr> their build, javac is part of the definition of _how_ a project
sr> gets built. A better way of looking at this is that all of the
sr> tasks are merely tools, and have a meaning independent of how
sr> they are used.
Maybe I am getting closer to your point of view here. Now there is a
need to use some other tasks the same way as property and taskdef -
and this should even be OK for me as they are on the _how_ to do
things part of Ant, right?
It still doesn't feel right. I think I need to find out why before I
continue.
Stefan
