OK Stefan, I now see you were serious about your response to my other response ;-) Lets talk about ANT2.
Before I comment on your points below, let me just say that from the design point of view I would like for ANTx parser (i.e. ProjectHelper) to be as agnostic about the structure as possible. That would mean that ANT can be evolved in ways we do not forsee at this time, without the need to change CORE every time. It will allow for a richer sets of tasks to be developed by other projects that could use ANTs component model as the basis. With that in mind: From: "Stefan Bodewig" <[EMAIL PROTECTED]> > 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? > > (1) Allow no tasks to be defined at the same level as <target> (this > is what Tim Dawson has proposed IIRC). > When we say "no task" do we actually mean "nothing can be outside a target"? In other words what do we do with "types" can they continue to be declared outside? The fundamental issue here is this separation between "type instances" which can be declared outside tasks and tasks that declare instances of things which would not. The combination of the two wd make things quite unusable. I also think that if we adopt this proposal, the resulting pattern for buildfiles will be having all targets expressing dependency on one "init" target. If people do not think so, I would like to see one useful buildfile for a project with targets that do not require the usage of any properties. So at the end we will finish with a very redundant pattern. Finally, what is the meaning of "ant target1 target2"? In the current implementation, the "init" target from which "target1" and "target2" depend will be executed twice. Which is probably not what we want ant to do, it is certaintly not what we mean when we put things outside a target. > (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-). > Although this may be an alternative, it may be something run a mock solution. Most tasks make little sense to be outside of a target. In general, what we want outside are things that may be needed in order to be able to parse the rest of the file correctly. The major examples being different forms of declarations and other objects required to perform such declarations. It may make sense to try to separate these two kinds of tasks given its different functionality. > (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). > Not surprisingly, this is the one I prefer :-). The point here is that there are certain tasks whose Job is to declare things to be used in the rest of the project those include <property>, <taskdef> and <typedef>; and in the future they may include things like the proposed <antlib> and even <projectref>. There is no reason for the core to have to be aware of such things since tasks can perform the work just fine without ProjectHelper being involved. As the discussion on <antlib> will bring to mind, we have not exausted the list of tasks that can be declaring things on a buildfile. And hence it makes more sense to provide ways for a generic mechanism that does not require changing core everytime. > (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). > This I think is the worst thing we could do. It produces comical situations like <taskdef> being allowed outside targets but <typedef> not being allowed, I guess it was forgotten. It will only produce inconsistent usages and breaks the simetry between core and user defined tasks. In other words it creates a two tier system of tasks, there is no reason for this at all. Jose Alberto
