ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <d.ree...@usa.net>
Subject Re: Feature Request: Ant batching support
Date Thu, 08 Mar 2001 01:45:27 GMT
I should say up front that my interests for Ant2 are much more from a
design perspective than the actual functionality. I think what great
about Ant1 is its extensibility. I think that the core and the API it
gives to tasks (core or optional) for Ant2 is the most important thing
that needs to be decided. Then let the world write whatever they want
and we commit it in some common "let the user beware" add-on"
directory (something less tested than optional with different support
rules).

So, here is my suggestion that I first through out for Casey's request
on ant-user.


>How about a batch property task instead? Better syntax is certainly possible, but for
example:
>
><batchpropertytask
>   <batchproperty name="target" valueslist="clean,build,run" />
>    <batchproperty name="file" >
>        <fileset dir=".">
>          <include name="**/build.xml"/>
>        </fileset>
>  </batchproperty>
>   <ant
>       antfile="${file}"
>        target="${target}"
>        output="ant-result.txt" />
></batchpropertytask>
>
>Then you could slap this around anything you want.

As Stefan mentioned, "foreach", but now I have thought more about and
I think this fits better into this API that I had thought about.

Generally all tasks act on a file should actually be able to act on a
set of files as well. I would also generalize this that Tasks that can
act on a A should be able to act on a set of As. For simple tasks ANT2
should automate this somehow. For smarter tasks they can actually ask
for the whole list and do something smarter.

Perhaps something like
setBuildfile(File aFile)
for simple tasks and
setIteratorBuildfile(FileSet aFileIterator)
for smarter ones like Copy.

Then for option1 Ant1 could automate going through the FileSet. Same
thing would apply for lists of strings or files of strings. Obviously
there are some questions of how to keep ordering if there are multiple
sets (e.g. fromfile and tofile).

Going further, you noticed I used set instead of add/create (I hate
create BTW). I think we need to look at better understanding the fact
that the attribute/element is very blurred in XML and that Ant blurs
it much more. We need to support a common way for indicating either
will work in a Task. Includes being good example. Do we even really
need a element for that, or could we support
setIncludes(String aString)
and then Ant will automatically allow a set of internal elements named
includes and then iterate on the task based on them?

dave

On Wed, 7 Mar 2001 08:20:12 -0600, John.D.Casey@mail.sprint.com wrote:

>As per Mr. Bodewig's advice, I'm submitting this suggestion to you 
>folks in the hopes that we can work something out in the future...
>
>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.
>
>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.
>
>Also:  I'd like the ability to specify <ant keepenv="true"...>, or 
>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...
>This is different than using the <property file="filename"/> task, 
>since it also allows the initialization of common <taskdef> and 
><available> tasks, as well as others.
>
>If you'd be so kind, would you please consider these changes in the 
>near future?  If needed, I should have some basic code examples of 
>these implementations by the end of today.  I could easily email these 
>changes to the list, if desired...
>
>Thanks in advance,
>John Casey


Mime
View raw message