ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt Huwig <>
Subject Re: Ant2 suggestions
Date Tue, 17 Jul 2001 07:24:33 GMT
Maurice le Rutte wrote:
> > [...]
> > So, comparing just the dependencies, make is more powerful than ant, but
> this
> > is not all ;-)
> I've never hacked much makefiles myself as NeXT's ProjectBuilder was better
> at this than me,but I can't see why make would be more powerful than Ant
> just because the rules are specified differently. I really like the fact
> that I tell Ant 'I want this. To get this do foo, bar and baz. To get foo
> do...' . Can you explain what nifty feature I should be missing in Ant that
> makes my life misarable?

I just meant that make can do what Ant does but not the other way round as
long as you look at dependencies only. I didn't say that this is a feature
you really need in everyday work. In fact, dependencies are less important
with current machines that rebuild even large projects in just a few
seconds. Back in 1993, our C project at university needed about 45 minutes
to rebuild, so this was quite important. Ant is much faster than make when
it comes to Java applications, so that's why I switched to Ant.

> > [..]
> > make was written for C programs and deals very badly with directories.
> Most of
> > the time, each directory needs its own makefile.
> I must have been abusing make, we had only one makefile per project and
> we've always used sub-directories quite a lot.

Then you must have been better than me ;-) I do also have projects with only
one Makefile, but this makes concurrent development a pain in the ass, as
every developer needs to modify the makefile when adding files to the
project. With Ant, you just rebuild a directory which is much easier.
> > I like to reduce problems to the very necessary,
> > because I don't want to learn much. Everything should be as intuitively as
> > possible.
> Laziness is a virtue when programming. However, what is intuitive differs
> per person and is largely based on past experiences. The biggest mistake is
> to use yourself as the center of universe.

I am not the center of the universe, as this is Germany ;-) Just kidding. I
don't know if it is easier to judge if something is easy to understand for
someone else than it is to judge for me. I just can see what looks easy for
me and ask others to comment about this.
> > 1. filesets
> > ------------
> > Ant deals with file conversion. You have input files and outputfiles and
> tasks
> > what to do with them. Right now, both writing build.xml files and tasks
> > itselves it more complicated than necessary.
> > Each task can have input-files, output-files. Some of the build-in tasks
> just
> > need one of them, like 'mkdir' or 'delete'. Nethertheless, the syntax
> should
> > be similar, as it is obvious that 'delete' does not create files.
> >
> > A possibility would be>
> >   <mytask in="...." out="..."/>
> > (this could also be 'from' and 'to') or
> Arguments names should be descriptive of what they are used for. If two
> tasks can share the same name, great, but don't enforce names. The names
> you've suggested seem a bit too general for me.

That's correct. But you can use the same code for all tasks, so that you
don't need these 'createFileset'-methods replicated in each task. But you
can handle this very easy by using task-specific properties that tell Ant
the name of the parameters for these, maybe like this

  public class MyTask extends Task {
    public MyTask() {
      setInFileName( "source" );
      setOutFileName( "target" );

> > Right now, the semantics using several filesets is confusing. If you have
> > (version 1)
> >
> > [...]
> > then both 'a' and 'b' are sorted and given to the task as one fileset,
> thats
> > ok. But if you have (version 2)
> > [...]
> > 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)
> > [...]
> > and should not be like this, as I can write it like this if I want it. My
> > suggestion is:
> >
> > version 1: all files are sorted
> > version 2: files are sorted within the filesets, but not sorted across
> them and
> >   given to the task as one large fileset
> > version 3: several filesets, several calls to the task
> >
> Could you explain what trouble it causes? Don't fix what isn't broken.

The problems where stated below this one with the 'cat' task. I have several
files that need to be put together in a certain order. First one file, then
a bunch of files in another directory and then another file in the same
directory as the first one. I want to use a mapper, so that this file is
only being rebuilt if necessary. If I write all the files in one fileset,
they are being sorted and I get the second file directly after the first
file an especially before the bunch of files. If I use several filesets,
each fileset is a separate call to the task and a separate check with the
mapper, so Ant just adds the first file and then says that the target-file
is up-to-date as it is newer than any of the other files.

I could not figure out how to handle this problem, as I don't know how to
tell Ant file dependencies and so I just removed the mapper in my task and
rebuild the file on each compilation to be on the safe side.
> > Additionally an option 'parallel="false"' that switches to 'one file at a
> time'
> > mode.
> Task specific, imho.

Certainly, but if you can use it for every task, it is consistent. It might
even be resonable for the 'javac'-task, if you are low on memory.
> > [...]
> > 3. fileset-code for tasks
> > --------------------------
> > When writing a task, accessing the filesets and mapper is rather
> complicated.
> > Code like
> >
> >   fs.getDirectoryScanner( project )
> >
> > where 'project' is inherited from a super class is not very object
> oriented.
> What exactly is not 'object oriented' about this construct? The fact that a
> task inherits its project or that the fileset needs the project to setup the
> scanner?

Inheritance of fields is a Bad Thing (tm) IMHO. The same for the fileset's
need of the project. The fileset is created by Ant, so it should know the
project. You can also use the Singleton-pattern to remove the need to refer
by a field. Hotspot optimizes getter and setter-methods, so you don't even
have a speed advance if you access the fields directly.

Just imagine having the need to switch to several projects for whatever
reason. Then you have to change every line of code that refers to 'project'.
If you use 'getProject()' instead, you just have to change the code of this
method and that's it. I had the problem of changing a software from single
document to multi document interface and was glad for using access methods.

> > Also, the files should be accessible as an 'Iterator' over 'File'.
> I tend to agree on this one. I think all objects that have a containment
> relationship with other objects should have an iterator. Unfortunately even
> Sun doesn't do this. Look for example at the Servlet API and in 1.4 the
> NetworkInterface  class...

This is not a reason for me to do the same mistake...
> > As there is only one fileset, the Iterator itself should be sufficient.
> Don't agree here. Use a collection. Collections can return iterators.
> Doesn't complicate things and doesn't force you into a specific way.

Ok, you are completely correct. I just didn't think about this enought.
> [...]
> Maurice.

Thanks for you feedback,

Dave. Stop. Stop, Dave. Will you stop, Dave? I'm afraid.
I'm afraid, Dave. Dave, my mind is going. I can feel it...

View raw message