ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: [RFE] Richer Task Specification
Date Tue, 20 Jun 2000 12:36:30 GMT
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  <rubys@us.ibm.com> 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

Mime
View raw message