Peter Donald writes: > > In fact, the property/available/etc. might be required in > order to do task > > definitions properly. > > -1
How about an explanation of your reasoning? How about if I use an environment entry that is required to find the location of a jar file that has my tasks in them? > > Right now, its possible to define a task after building it > in the same > > file. Or at least it was with 1.3, I haven't tried it in a > while because > > I'm on some new projects that don't need that. > > it will still be possible in ant2 but the standard approach > will be to use > <import/> (like import for java). Thus hopefully the use of > oldstyle taskdef > will be minimized. How, then, will this be possible if you plan to do up-front validation, i.e. before the task has been defined? Or does it simply note that a taskdef has occurred with the name and continue on? sounds like a lot of hardcoding in the parser to me. > > Executing the init target (if defined) would validate it > (it would fail if > > it wasn't valid). You could then validate the rest of the > file. Problem > > solved, > > as far as I can see. > > the solution to problem is to avoid problem? I don't see that > as a good > thing. We want to validate the build file as much as we can > before execution > starts. I'm sorry, I don't see why we *need* this. Can you point me to the relevant thread where this was decided so I don't have to have you explain it to me? > > > c) not intuitive - imagine you had to search through a > > > java file for an init method and inside that was located > > > all the java import statements. > > > > No, I think its very intuitive. Imagine you had a method in every > > object that could get called when its created. Oh, wait, > Java does have > > those, they're called constructors. :-) > > eh? > > You were talking about "supposedly preprocess/validation > requires top-level > tasks". These constructs are not tasks but import statements. > What place do > they have being in a constructor ? fair enough. I was thinking about another thread related to defining properties (i.e. build instance variables) inside the init target (i.e. constructor). Tim -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
