At 09:54 PM 4/18/02 -0400, you wrote: >----- Original Message ----- >From: "Ray Tayek" <[EMAIL PROTECTED]> >To: "Ant Users List" <[EMAIL PROTECTED]> >Sent: Thursday, April 18, 2002 8:59 PM >Subject: some design questions about "ant in anger" > > > > hi, i am digging thought the "ant in anger" article ... > >I encourage you to have a look at >Maven. ... http://jakarta.apache.org/turbine/maven/
looks interesting. i will probbaly try it out when i am ready to write that "...single set of Ant files are used to build any number of projects that you are managing". > > also, i am a bit confused about properties. afaict, these are immutable > >correct, they are immutable. > > > ... if you wanted to override some property, you would need to somehow > > process your build.properties in a "bottom up" manner ... > >you set your properties in precedence order, and the command-line >(-D/-propertyfile) options take ultimate precedence. because the first guy to define it gets it his way, correct? > > 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? when ant sees new build.xml and build.properties files do these > > "go away" when that ant call terminates? > >I'm assuming you mean <antcall>? Or <ant>? i was thinking of <ant> (did not know about antcall) and was assuming that the build file would be from a sub-directory of the current ant task (but i can see from the doc that this does not have to be the case - neat!). > Either way there are options to pass properties down from the calling build oops, i should rtfm more :( i also see that if you do not inheritAll (properties), then it looksl like you can still access the "outer" properties by using something called "nested property tags". >and in Ant 1.5 even references. excellent! > Properties do not pass back up though (unless you do some tricks ... > > > 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? > >These all play fine together, and all are actually JUnit tests anyway, so >they could even all be run in one <junit> task (although I separate Cactus >and regular JUnit tests). HttpUnit tests would be wrapped in a JUnit test >case, typically, and pretty much any other test I'd perform would be too. i think i would lobby for more separation of the different kinds of tests. if a bunch of your junit guys fail, the you probably want to bail or just for organizational reasons. i was thinking of putting the different tests in different source directories and keeping the junit tests in the same package (so i can test protected methods easily) but in a different source directory (i would expect helper classes to hang out here). >What specific issues are you having here? nothing specific, i am just getting started :) thanks for the assistance --- ray tayek http://home.attbi.com/~rtayek/ actively seeking telecommuting work vice chair orange county java users group http://www.ocjug.org/ mailto:[EMAIL PROTECTED] hate spam? http://samspade.org/ssw/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
