----- Original Message -----
From: "Ray Tayek" <[EMAIL PROTECTED]>
To: "Ant Users List" <[EMAIL PROTECTED]>
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
the
> 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 build.properties 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
any
> luck with putting different kinds of testing like these ant?
cactus needs ant; httpunit is simply another junit target you run *after*
deploying.
so it goes
build
unit tests
deploy
httpunit
cactus
-maybe swap http unit and cactus if you want
-steve
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
