ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Mon, 22 Oct 2001 12:48:01 GMT
Stefan Bodewig wrote:

> As it stands, a couple of tasks can live at the same level as
> <target>, but they are hard coded by name.  How do we want to handle
> this in Ant2?

Another fascinating Ant2 thread. Typically long and with the usual 
suspects, with the same hard edge (hey, trying to look on the bright 
side :-) ). Anyway, let me chime in with some late comments on various 
points made throughout the thread.

I agree with Jose Alberto that the parser (currently ProjectHelper) 
should not have any "special cases", such as the current test 'if name 
== "property" doBlackMagic()'. However there is a limit to that. There 
are some constructs in the buildfile which should be recognized and 
handled by the parser and not delegated. This is necessary because some 
of these constructs deal with fundamental core datastructures. I agree 
with Peter that we want clear separation between core components and 
user tasks through a clear well-defined interface. I believe this is 
necessary to support a proper classloader hierarchy - there will be core 
classes that cannot be made available to tasks, without coupling 
classloaders and the nightmares that brings. We need something similar 
to the servlet engines which carefully structure their classloader 
hierarchies and, require clear separation of classes (responsibilities).

I'm not sure why Peter believes we won't need <taskdef> at top level 

Let me say, at this point, that I like the current Ant pattern of 
declaring <property>'s outside of all targets. Why? Firstly, the 
construction appeals to me since the static structure reflects somewhat 
the scoping. To define properties in one target and then use them in 
another loses that static structure. To understand the build file at a 
high level, you need to examine its dynamic structure. ("This property 
is used here in target X, this target depends on target foo, which 
depends on target bar which, aha, defines the property"). Global 
properties in a build file are like that, you want to see them plainly - 
it gives you a quick idea of what you control in the build. It is for 
this reason that I also think the argument that I can have a 
depends="init" on every other task is a little problematic - it loses 
the structure, and I believe it is also error prone. An <init> block 
would be OK, if more structure is required, but I think global 
properties need to stand out from the general dependency structure.

I haven't look in detail at Jose Alberto's <antlib> proposal, but my 
concern, from an Ant2 perspective, is how it works within a defined 
classloader hierarchy. There will just be some classes that it needs to 
use that, being in "user" space as it were, to which it will not have 
access. Perhaps this implies a need for an extension mechanism that 
allow some tasks to extend the core operation but which are loaded 
within the core's classloader, or a child classloader - I'm not sure at 
this stage. Is it flexibility syndrome or a sensible design for 
extensibility? That is probably personal opinion. We could leave it out 
to start with and then add it in when the need arose.

Stefan said "I don't want to distinguish between the definition of a 
datatype and a task that does something else". that is an interesting 
point, I think. In mutant, I tried to treat <datatypes> as tasks which 
modified Ant's internal environment, rather than its external 
environment. It needs more thought especially in terms of references. It 
is interesting to look at what most people think of as Ant's most 
fundamental datatype to discover that it is a task and not a datatype at 
all. Some of that comes from the multitude of things the <property> task 
can do, which perhaps it shouldn't. It does illustrate, however, that it 
difficult to distinguish a datatype and a task. The difference is in 
what effect they have. The referencible info created by a datatype task 
can be separated from the task, if you follow me.

With regard to undefined properties causing a failure, rather than 
becoming the value ${ljljlkj}, I agree with this. I don't think it was 
ever agreed, and in fact, IIRC JDD was against it. I believe in a more 
explicit Ant, much like Java where use of something which is undeclared 
is an error. The looser, implicit, script-like approach is more error 
prone, IMHO. This can be done in Ant 1.x now since I fixed up the 
original need for the looser model (out of order properties files)

We have agreed to unify the namespace of properties and other "types" 
but not necessarily the contructs used to declare those elements.

Finally, a note on tone :-). If we can't conduct an even-tempered 
discussion without much of the undertone, then Ant2 is probably doomed 
for the dustbin.

> (1) Allow no tasks to be defined at the same level as <target> (this
> is what Tim Dawson has proposed IIRC).

-1. If top level tasks are deemed undesirable, I believe an <init> 
structure should be provided. Sure it is a convenient shorthand (I don't 
like using java.lang.String, either) for having depends="init" 
everywhere but it is an explicit representation of the concept.

> (2) Allow all tasks to be defined at the same level as <target> (I
> don't know whether he remembers it, but Sam Ruby proposed this about
> fifteen months ago 8-).

Unify datatypes and tasks and allow this: +0

> (3) Allow all tasks that implement a given marker interface to be
> defined at the same level as <target>s (Jose Alberto Fernandez
> proposes this and has already supplied a patch that enables this in
> Ant 1.x).

These aren't tasks for classloader/separation reasons. +0 on a core 
extension concept implemented this way.

> (4) Keep it the way it is in Ant 1.4 - only a fixed number of tasks
> can live at the same level as <target> and their names are hard coded
> in Ant's core (don't know of a proponent).


> Are there other options?

Not sure if my answer to 2 is a different option.


View raw message