ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [RFE] Richer Task Specification
Date Tue, 20 Jun 2000 10:25:50 GMT

> The most obvious reason is that task are not allowed outside of
> targets (and this is one thing I really want to keep). This would
> mean that properties and taskdefs had to go into a target probably
> named "init".

And I don't want to reinvent "init".

> You might not know this but there has been some confusion some
> months back. First property behaved as it does now, then it was
> forced to be inside a target (and many build files were changed
> to reflect this) then there were a lot of complaints and it was
> changed back. I don't want to add another iteration to this.

What actually happened was that a number of people objected to the special
meaning associated with the "init" task.  There was nothing in the
build.xml which indicated that this task was special, but it behaved
differently than all of the others.

It is this behaving differently that causes confusion.

> My primary reason is another thing though. To me tasks "do
> something", they provide some kind of external action to get the
> project built. Property and Taskdef are somewhat different,
> they change Ant internals, they decide _how_ a project gets built.
> Therefore they are not tasks to me.

It is a matter of definition.  I believe "set" would be a more accurate
description of what "property" now does.  If property were truly
declarative, then any declaration of a property within a target should be
scoped to that target.

And to the people who want to compile their taskdefs as part of their
build, javac is part of the definition of _how_ a project gets built.  A
better way of looking at this is that all of the tasks are merely tools,
and have a meaning independent of how they are used.

I didn't mention it in my first mailing, but making the execution of a task
dependent only on the positioning of this task in the XML would mean that
init could be made to go away.

> Maybe this is some kind of private philosophical distinction
> without any meaning to others, I wouldn't vote against treating
> them as tasks even if I feel the are not tasks.

There is nothing wrong with philosophical distinctions.

If we decide to propagate this distinction, I would like to see some
difference, evident to the casual reader, between the two types.  Example,
make the purely declarative tasks processing instructions, e.g..,

On balance, I feel that unifying all tasks would result in the simplest and
easiest to understand system.

- Sam Ruby

View raw message