> I'm seeing the need for this on the new taglibs project -- the general
scenario
> is semi-independent sub-project builds controlled and monitored by a
master
> script. I like it.
Actually, instead of entities, I think that I like the:
<target ....>
<ant buildfile="foo/bar/build.xml"/>
</target>
approach to recursion of this sort.
> > Targets now have a condition. This is debatable, but was added by
> > Stefano for a very simple reason: he had a job he needed to get done
and
> > nobody had any better suggestions at the time.
> >
>
> The implementation isn't bad, and it's going to become a much bigger issue
for
> Tomcat as it grows. Consider -- what if we wanted to provide a tomcat
> implementation of the application environment stuff in Section 9.9 of the
> servlet 2.2 spec? License issues aside, Sam would fly across the country
and
> wring my neck :-) if I checked in the JNDI binaries. Now, do we want to
throw
> hundreds of compile errors if the poor unsuspecting user doesn't have the
JNDI
> classes in their class path, or do we want to be smart and just build what
we
> can?
This is conditional compilation, not conditions on target execution.
Different things.
> With taskdef, we have a strong argument that Ant's core should be limited
to
> the things that *everybody* needs. Any project that needs something cute
is
> more than welcome to add their own taskdefs, ***in their own project
source
> code***, and not increase the complexity of Ant itself. Without it,
there's
> going to be intense pressure to add this new "mission critical" task
that's
> needed by project XYZ, and you get an unusable mess.
There also needs to be a way just to have contrib or optional taskdefs
installed into the system so that you dont' have to use taskdef.
.duncan
