ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <>
Subject Re: Ant allegedly becoming a perl
Date Tue, 11 Apr 2000 01:29:46 GMT
> I'm seeing the need for this on the new taglibs project -- the general
> is semi-independent sub-project builds controlled and monitored by a
> script.  I like it.

Actually, instead of entities, I think that I like the:

  <target ....>
     <ant buildfile="foo/bar/build.xml"/>

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
> >    nobody had any better suggestions at the time.
> >
> The implementation isn't bad, and it's going to become a much bigger issue
> 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
> wring my neck :-) if I checked in the JNDI binaries.  Now, do we want to
> hundreds of compile errors if the poor unsuspecting user doesn't have the
> classes in their class path, or do we want to be smart and just build what
> 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
> the things that *everybody* needs.  Any project that needs something cute
> more than welcome to add their own taskdefs, ***in their own project
> code***, and not increase the complexity of Ant itself.  Without it,
> going to be intense pressure to add this new "mission critical" task
> 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.


View raw message