ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Ant2 suggestions
Date Tue, 17 Jul 2001 12:04:21 GMT
On Mon, 16 Jul 2001, Kurt Huwig <kurt@iku-netz.de> wrote:

> Both make and ant serve to ease the job of creating files out of
> other files.

Ant not so much as make, as what would be a PHONY target in make is
nothing special for Ant.  In effect, the whole build process is mostly
about creating files from files, but Ant doesn't really focus on this.

> What ant lacks compared to make is the dependency based on files,
> but later more on this.

Please take a look at the <apply> task.

> 1. filesets
> ------------
> Ant deals with file conversion.

Not really - <sql>, <junit>, <mail> do not really work on files at
all.  If you leave out the <batchtest> element of JUnit there are no
files involved at all (as far as Ant is concerned) for example.

> if you have (version 2)
>  
>   <mytask>
>     <fileset>
>       <include name="b"/>
>     </fileset>
>     <fileset>
>       <include name="a"/>
>     </fileset>
>   </mytask>
>  
> then 'a' and 'b' are not sorted and given to the task in two
> separate calls as two separate filesets. This is the same as
> (version 3)
>  
>   <mytask>
>     <fileset>
>       <include name="b"/>
>     </fileset>
>   </mytask>
>   <mytask>
>     <fileset>
>       <include name="a"/>
>     </fileset>
>   </mytask>

No, these are different.  <chmod> in current CVS will create a single
call to the chmod utility in the first case (your version 2) - it is
up to the task to decide what it wants to do with several filesets.

> 2. mappers
> -----------
> Mappers allow ant to do 'shortcuts' by not applying tasks if the
> outfiles are newer then the infiles.

This is not their primary purpose - they are used to define the target
files with respect to the source files in the first place.

> Right now, the usage of mappers is very limited.

True.

> together with the strange behaviour of version 2, you cannot use it
> to 'cat' (UNIX cat) several files together if you need a certain
> order.

Two things here:

(1) you can use it with Unix cat using <execon> and the parallel
attribute - it will be one call per fileset in Ant 1.3 but really just
one call in the current CVS version.

(2) Ant doesn't guarantee any order - even within a single fileset.

> My suggestion is, that a mapper is possible for every task and that
> it is evaluated only once.

Where they make sense - see <mkdir> or <junit> or ...

Again, it is up to the task to decide what it wants to do with
filesets or mappers.  Which built-in task should support mappers in
what way in your opinion?

> 3. fileset-code for tasks
> --------------------------
> When writing a task, accessing the filesets and mapper is rather
> complicated.

Agreed.

> Also, the files should be accessible as an 'Iterator' over
> 'File'.

This has been suggested before - there are times where you want to
operate on a set at once and times where you want to iterate through
the set.  I guess we'll end up with an Iterator approach as
alternative to methods returning the whole set at once.

I'm not sure about the File though, we have filesets that work on
remote directories (see <ftp>) or ZipEntries (see <zipfileset> in
<zip> and friends).  We'll probably end up using a different
abstraction than File.

> The mapper will create the corresponding filesets and will be used
> to check if the task needs to be run or is up to date.

I'd prefer to keep this responsibility (does the task need to run)
inside the task itself, as only the task can now the logic it has to
follow. See the various overwrite or force attributes in some tasks
for example.

> 4. shortcuts for targets
> -------------------------
> Sometimes it is quite hard to convince Ant that a target does not
> need to be rebuilt. What about a mapper for the target itself, just
> state what files this target needs and what file(s) it creates.

<target>s don't have input or output files for me.  A <target> groups
tasks and these tasks are supposed to be smart enough to know whether
they should run.

Stefan

Mime
View raw message