ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject That's what I was gonna say....
Date Mon, 18 Dec 2000 18:27:27 GMT
--- Ken Wood <> wrote:
> How about the good old fashioned way:
> 1. A requirements specification that spells
>    out WHAT the software must do, without
>    ANY indication of how it should be done.
> 2. A design document that specifies HOW the
>    requirements will be met via a proposed
>    implementation.

I realize I'm only a lowly end-user (with a couple of very minor patches
submitted) and I don't have any voting rights, but if I -were- able to
vote, I'd vote for this.

Now that Ant has been getting used in the Real World for awhile, it seems
to me that the greatest resource available to help in the design of an
Ant2 would be to gather information from users -- find out how they're
using it, what they like, what they don't like, what they need to do and
currently can't, etc.

I've been trying to keep up not only with the proposals as they're
submitted but with the discussions about Ant2 in general and the various
proposals in particular, and I'm sorry to say that, at this point, I still
have no clear idea of what any of them will or won't do for me with regard
to what I will or won't be able to do with an Ant2 that I can't currently
do with Ant1.n -- and there are definitely things I can't currently do
that I would very much like to be able to do.

As an example, both Make and Jam allow you to define "rules", which Ant
doesn't allow you to do. I've "faked" that functionality some, where I
can, by having "template"-type targets, that I then use <ant>/<antcall> to
pass the values that slot into the target's tasks' attributes. But there
are only a very few targets I can do that with (eg. parser generation) --
but a target that does Java compiles isn't one of them. So in every
build-file that includes targets that do compilations I need to have the
same lines of XML over and over:
        <pathelement path="${compile.classpath}"/>
      <include name="${com.dir}/path/to/subdir/**"/>
The reason I can't "template" that is because the classpath can, for some
<javac> tasks, need additional <pathelement>'s, and the task can require
additional <include>'s and possibly <exclude>'s -- and I can't see any way
to do that with Ant as it currently exists. I recently added the "proceed"
attribute, which meant editing 65 build-files, many of which have far more
than one <javac> task. Obviously, this is an arduous task (no pun
intended), and will only get more so as the number of build-files

I also very much miss having a simple way to include other files (the
ENTITY thing doesn't really do it for me -- 1) it's not simple, and 2) it
doesn't resolve property references for the filename).

The other thing I'm not thrilled about with Ant is the XML build-files --
they can be rather daunting to people who are used to dealing with, say,
Jam build-files, which can be as simple as, for example:
  Javac foo bar baz ;
because all the "bones" are in the rules files, so all the developers need
to worry about is adding or deleting a source-file name to the list of
files to be compiled.

I'm not saying I -prefer- Make or Jam over Ant -- if I did, I wouldn't
have just gone through a massive conversion of a Jam-based system to be an
Ant-based one. There are *definitely* advantages to using Ant for a
Java-based product, and I fully intend to continue using it -- I would
just be happier to see a greater focus, at this point, on -what- Ant does
and doesn't do than on the -internals- of how that's to be accomplished.



Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

View raw message