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 anymore.
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).
-1
Are there other options?
Not sure if my answer to 2 is a different option.
Conor
