ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ara Abrahamian" <>
Subject RE: [VOTE] target-less build files (plus a new proposal)
Date Sun, 19 May 2002 18:11:43 GMT
It's like a book without chapters :-) Boring, non-modular.

With targets you have a simple mechanism to define small functions in
your build, call them, depend on them. Like you "extract variable" in
refactoring of your java code, you also "extract target" in your build
file, you give it a good name and the build file is more readable then.
I really don't find a target-less build file useful. Ant's build files
are generally hard to read and target names help a lot to understand
what's going on without digging into individual task usages. Some target
names like "main" are generally used everywhere as the base target. And
imho, like Java language itself, we should encourage ppl to use good
practices and even disallow bad practices, or leave them out of the
system at least, like Java.

Why should you use a target-less build.xml? Why? What is it you think
it's useful? :-)

Btw, I'm not sure we got into any near-term conclusion about reusable
build files. Seems like Myrmidon has some templating functionality, but
nothing for the 1.x line. What I really like about Tapestry web app
framework is how it handles reusable components. Say I want to define a
reusable ContactList component which shows a set of names/phones in
table rows/columns in my dynamic html page and use it in different
pages. I do it like this:
I define a ContactList.html file, there I define the html look of the
component (note that in jsp you define it in java code):

  <table class="BigFont">
   <span jwcid="forAllContactRows">
    <tr valign=top>
        <span jwcid="insertName">Name goes here.</span>

Then there is a jwc file, I define the caller interface of the
component, plus the fill in the blank parts (marked with jwcid

  allow-informal-parameters="no" allow-body="yes">
  <parameter name="contactRows" java-type="java.util.List"
  <component id="forAllContactRows" type="Foreach">
    <binding name="source" property-path="contactRows"/>

So there's this <parameter/> element, the user knows that it should pass
a List to the component, and forAllContactRows and other jwcids are
actually defined here (forAllContactRows uses Foreach component of
Tapestry, for example). Ant tasks are like jsp taglibs, a code is behind
the task, not a piece of a build file. Note that if I want to do some
code-behind-component, I just change the class attribute to point to my
class, and put my sophisticated component logic there.

What's got this to do with Ant? Well, think of ContactList.html a piece
of a build file. I use <jar/>/<javac/> and other tasks of Ant. Now
forget about the <component/> in the ContactList.jwc file, but
concentrate on <parameter/>. I can define input parameters for my build
components. It's waaaaaaay cleaner than the current approach of Ant: ant

So what I'm proposing is a single .arc file (Ant Reusable Component!),
with a <component/> root element and this root element has some
<parameter/> elements which defines the parameters the ARC accepts (say
the compileDir/srcDir/etc for a reusable ARC which does the compiling
steps for me). Now whenever I want to define a reusable ant component I
just create an .arc file, define the parameters there and use it like

<target name="x">
	<component-alias name="compile" path="./compile.arc"/>


So now I have an easy and modular way of defining build pieces, reusable
build scripts. Note that it let's you create components but the need for
overriding or calling or depending to targets in this or other build
files still exists and I think a fair amount of discussion went on
recently on this subject (but I'm not sure about the end result!). Imho
this <parameter/> mechanism should be used in definition of targets too.
Some targets have depends="", some don't or shouldn't because they
should only be called with an antcall. So for those only callable with
an antcall we can define a clean interface by using <parameter/>
elements in their definition. Relying solely on globally defined
<property/> elements is bad. An added benefit of this system is that we
can probably pipeline outputs of one build piece to the other build
pieces (or maybe call it buildlets?! I like this name!). Get a list of
files from one component as an out parameter, flush it into another one
as an in parameter.

So what do you think?


> -----Original Message-----
> From: Diane Holt []
> Sent: Sunday, July 21, 2002 3:05 AM
> To: Ant Developers List
> Subject: RE: [VOTE] target-less build files
> --- Ara Abrahamian <> wrote:
> > - A build without any targets is a bad practice, isn't it?
> Why? What is it you think will happen?
> Diane
> =====
> (
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message