> -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 4:51 PM > To: Ant Users List > Subject: Re: Help with designing Tibco Interface builds
> ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, August 09, 2002 4:24 PM > Subject: Help with designing Tibco Interface builds > > > Put on the spot right today, It's august 9th, and I got to > have everything > tested and ready by the 22nd, and I've decided to use Ant as > my main release > tool, and I'm a real novice at this Ant stuff, no wonder I'm > panicking right now. > From: Shawn Cretti [mailto:[EMAIL PROTECTED]] > Sent: Saturday, August 10, 2002 1:54 AM > To: Ant Users List > Subject: Re: [OT] Re: Help with designing Tibco Interface builds > > 'do I do it quick using what I know, or do I do it using Ant...and learn something >new?'. To releive the pressure, I've decided to do a manual build, learn from it, document it, then take the time to design the thing. > > To top that, I'm the only knowledgeable Ant person in the > team. Tough job when it's done and I try to explain it to them. Did I mention that I am just a beginner? And after making that crazy decision (choosing Ant in this environment), I got to make it a success or I'll blemish my name forever. > > This Tibco project has 25 independent interfaces (or components used > interchangeably here), plus 1 common/shared component. I > should be able to > say: build interface1 intf5 and intf15 for example > > > > The directory structure is like this > > > > root/ > > /shared > > /interface1 > > ... > > /interface25 > > Question 1: How would I design my build.xml? I do not see how I can > parametrize a task like a function call and pass it the top > directory of the > interface and maybe lateron other properties (I'm still very > much scripting > in my mind). Or do I copy the same build.xml to each > interface and call it > from the top level interface? > > > I'd consider a separate build file for each interface > (assuming it has code > underneath). If the steps to build each file are essential > the same, then > you could avoid that by having a parameter driven target in > your single > build file that does the work. > > For separate files, use <ant>, for a parameterised single file, use > <antcall> to call targets; in either case they are like > subroutines where > defined properties dont trickle back up. So far, I've been told the 25 interfaces use exactly the same IDENTICAL build logic. some C++, some Java compile, some Oracle (no processing, only execution on the target machine), some (xml) file whose contents are to be translated (word substitution). Would you give me a simple example (at a high level) on how to call the subroutine using different parameters, using <ant> or <antcall>. Which of the 2 would you recommend: execution speed wise, easy-to-maintain wise. > > The build has some C++ and Java build part: that part, I > feel a little > more confident. It's what comes below that bothers me. > > > > Each directory has a MATRIX of where to deliver the files. > > For example: > > development:.../config/aaaa should go to machine1:/xxx/aaaa > > development:.../custom/bbbb should go to machine1:/yyy/bbbb and > machine3:/zzz/bbbb > > and lots of that kind of combination. > > > > How would you handle that? I'm tempted to do it in Perl, > since I'm already familiar with it. > > well, you can call ant from perl. OK I'll do it then. I have saved some sample perl calls from this Ant User List. > > to configure ant I'd use a property file in each directory > (or even an xmlf > ile with <xmlproperty>), and have ant load it in to get customisation > details and thanks for taking the time to answer. Suu -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
