ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <>
Subject RE: [Ant2] Tasks as siblings of <target>
Date Tue, 06 Nov 2001 09:56:57 GMT
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).


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message