ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: some design questions about "ant in anger"
Date Fri, 19 Apr 2002 04:45:46 GMT

----- Original Message -----
From: "Ray Tayek" <>
To: "Ant Users List" <>
Sent: Thursday, April 18, 2002 17:59
Subject: some design questions about "ant in anger"

> hi, i am digging thought the "ant in anger" article and noticed that the
> author

that'll be me :)

>recommends having standard top-level targets like: build, test,
> clean, deploy, publish, fetch, docs/javadocs, all, and main and using ant
> calls to pass the control down the tree. so it seems like while some of
> stuff (in the build.xml file) is generic (implementation), some of it is
> non generic (policy) and "knows" what's below in the build tree. it would
> seem that ant is smart enough to look at the build.xml file in each
> directory and do the right thing. is this more or less how it works?

well, you use <ant> to hand off whatever targets you want to projects in
subdirs; it is not automatic.

> there was a recent post from yingwang@uhunix2 about a directory called say
> buildtool that contained all of the JAVA_HOME, ANT_HOME properties (or
> perhaps the build tools themselves?). perhaps that should be one of the
> top-level targets?

not a toplevel target, but you should keep as much as you can in SCM; ant
and all other java libs can go in there. I draw the line at java versions,
oh, wait a minute, I draw the line at JDKs. We do have a JRE installer under
SCM so that when we burn CDs it pulls everything (even 50MB app server
installs) from one place.

> the author suggests having "internal" targets at each level like: init,
> compile, link/jar, staging. not sure what this is all about, buy it sounds
> sorta like the separation between interface (the standard top level
> targets) and implementation (the internal "targets").

more that you should have well known targets, be they public ones or
internal ones. Common names are good. If you give targets a description
attribute, then when you go
    ant -projecthelp
it lists them differently (in ant 1.5 it wont list targets without a
description except in verbose mode)

> otoh, if i am using ant calls, what happens to all of the properties that
> have already been defined by descending the tree up to the point of this
> particular ant call? do these properties get lost when the new ant call
> gets made?

your choice

> when ant sees new build.xml and files do these
> "go away" when that ant call terminates?

yes. View it as a heirarchical context of properties; as you return up the
chain the context gets rolled back.

> another issue that seems problematic is that of testing. we will be doing
> servlets, so there are at least four (4) levels of testing: junit, cactus,
> httpunit, and someOtherTesting. the cactus seems a bit complicated (he
> deploys in place somehow - i don't quite grok that yet). has anyone had
> luck with putting different kinds of testing like these ant?

cactus needs ant; httpunit is simply another junit target you run *after*

so it goes

unit tests

-maybe swap http unit and cactus if you want


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

View raw message