Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <3.0.6.32.20010308013357.0214f100@alphalink.com.au>
Date: Thu, 08 Mar 2001 01:33:57 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: Feature Request: Ant batching support 
In-Reply-To: <H000205007d9be2c.0983974811.kcopmp02@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:20  7/3/01 -0600, John.D.Casey@mail.sprint.com wrote:
>I'm looking to support a directory structure in my build process that 
>is fairly dynamic. In addition, most of the other developers on this 
>project don't know Ant, and really have no need to, other than to put 
>their source into the build.  Currently, every time someone adds a 
>package to the src directory, they then have to wait for me to put a 
>target into the master build file to include their code in the build.

Could I see your build file because that should not be the case - do you
have some odd packaging requirements?

>Here's my suggestion:  I'd like to have the ability to batch the Ant 
>task, using a <fileset> tag and the target specified as an attribute to 
><ant>, in order to provide implicit inclusion in the build process by 
>just dropping in a generic template build.xml into their package 
>directory.  Special cases could then be dealt with on a case-by-case 
>basis, wherein things like special targets could be included by me.

Such requests have been made before and almost universally it has been
suggested that some sort of pre-ant transformation stage
(XSLT/Velocity/CSS/Other) is the way to do this. However if you want to do
it this way in meantime then thats fine with me ;)

>Also:  I'd like the ability to specify <ant keepenv="true"...>, or 

-1

We have discussed the notion of scope before and I much prefer something
like adding a scope="parent" attribute to properties to force them "up".
This is something that I am 90% sure will be implemented in Ant2 in some
form or another. Would this be sufficient for you ?

>something like this, in order to preserve the environment of the child 
>project into the parent's.  This would be useful in setting a common 
>build environment from many build.xml files, which would, in turn, help 
>to elegantly support surgical operations like compiling only a certain 
>package, or junit testing it...

another way is to include a xml fragment via standard DTD method (see FAQ
for details).


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*