Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <20010109202956.74542.qmail@web9307.mail.yahoo.com>
Date: Tue, 9 Jan 2001 12:29:56 -0800 (PST)
From: Roger Vaughn <rogervaughn@yahoo.com>
Reply-To: rvaughn@pobox.com
Subject: Re: The RIGHT Direction for ANT (was Re: Problem using script task)
To: ant-dev@jakarta.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

I couldn't agree more.  This is how IMAKE came into
being - it provided developers with the ability to
specify build products at a higher level of
abstraction than Make allows.  Its major problems were
the number of different languages used, and the fact
that the default templates were tied intimately to X.

We have an excellent opportunity with Ant to repeat
the best of the past without keeping the mistakes. 
XML allows us to create higher and higher levels of
abstraction *while using the same expression
language*.  XSLT can be used to generate each lower
level script as needed - and Make or Ant can be used
to control the whole process.

One thing I have noticed lately is that increasingly,
particularly on larger projects, when I program Ant I
feel like I'm just writing scripts anyway.  I recently
wrote some Ant files to build C programs (for native
libs), and I *really* missed Make's ability to check
basic inter-file dependencies.  Ant hides this in
certain tasks - but in the interest of applicability
to jobs that Ant programmers haven't forseen, this
basic ability ought to be exposed.  Yes, I know about
the uptodate task - and it is a *very* clumsy method
for accomplishing this.  The Ant scripts I ended up
with are much larger and more complex than their Make
counterparts, and are mostly procedural in nature.  In
the absence of C-specific tasks - which I don't really
have the time to write - I would have been better off
using a combination of Make and Ant.

I know I have argued this in the past, but my
impression is that Ant is becoming more procedural and
less declarative with each iteration.  Much effort is
expended on tasks, and little on structure.  The whole
scripting question takes this even further.

I was struck by this after writing scripts for a
number of J2EE projects.  The bulk of my scripts was
concerned with *how* the output products are supposed
to be built, and much less with *what* was to be
produced.  What appears in only the sketchiest detail
is how various components are related.  I would even
go so far as to say that this detail was more or less
obscured.

As a result of this, I started a little side project
to take the build to the next higher level of
abstraction.  What I ended up with was an XML file
that describes the content and structure of the output
J2EE application, and almost no detail on how it was
to be constructed.  The how I put into a XSLT script,
which then produced an Ant file from the original XML.
 A small Ant file handles the translation process and
invokes the generated Ant file.  I was very pleased
with the results, but I have to admit that writing
flexible XSLT is not easy.  This parallels the IMAKE
experience amazingly closely - this was not my goal,
but is an interesting observation nonetheless.

The moral of the story (am I rambling yet?) is, in
essence I agree with Jerry.  Ant as is is suitable for
small projects.  This is not an insult, it is simply
the reality of the situation.  Adding the flexibility
to Ant to handle large, complex projects is likely to
make it unwieldy.  Instead, we need to focus on
keeping Ant as tight and declarative as possible, and
only add complexity by using mechanisms to express
projects at a higher level of abstraction than Ant can
(currently) handle.  XML/XSLT is an excellent tool for
this.  Templates tasks, complex dependencies,
iteration - all of these things can be accomplished in
XSLT, without requiring that the end user (exposed
only to the highest abstraction level) worry over the
complexities of the tool.

Roger Vaughn


--- Jerry Huth <jerry.huth@Sun.COM> wrote:
> 
> This discussion about whether or not ANT should have
> more advanced
> features such as templates is amusing because the
> obvious answer is
> that if your software system is so large that you
> need such advanced
> features, then your build system should include both
> a
> dependency-generation program as well as a
> dependency-reading program.
>...

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/