Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 57389 invoked by uid 500); 16 Aug 2001 21:59:50 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 57363 invoked from network); 16 Aug 2001 21:59:49 -0000 Message-Id: <5.1.0.14.0.20010817095048.00a6d750@actwel450> X-Sender: bevan.arps@actwel450 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 Aug 2001 09:56:37 +1200 To: ant-user@jakarta.apache.org, ant-user@jakarta.apache.org From: Bevan Arps Subject: Re: multiple builds In-Reply-To: <20010816212303.16927.qmail@web13002.mail.yahoo.com> References: <5.1.0.14.0.20010816104756.00a77ae0@actwel450> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_90223614==_.ALT" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N --=====================_90223614==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:23 16/08/2001 -0700, Sanjay Bhatia wrote: >I'm interested in seeing examples of buildfiles that work well for you and >those that you would consider very well organized. If you have copyright and >NDA issues to deal with please ignore this. Feel free to email me directly. There are some confidentiality issues which mean I don't feel comfortable with releasing the files directly. I can describe some details however. We've factored out a number of utility targets into a common file (Common.xml) which is included in all our other files using a standard XML trick involving entity definitions. (Search the archive for details). The targets within each file are systematically named. For example, we've termed each collection of related builds a "block". Inside block.ant you will find these targets: block.build.nnnnn - Do a production build of this block at version nnnnn block.src.nnnnn - Retrieve all the source code of this block at version nnnnn block.compile - compile the source code for this block block.document - document the source code for this block block.src.files - fileset listing all source directories This structure makes it easy to manage file maintenance. Eg: to add a new version of the block, we don't have to guess the names of the targets required. Invoking builds in other blocks (eg for core functionality) is easy because all blocks use the same system. Feel free to ask questions and I'll answer the best I can. Hope this helps, Bevan -- "Programming is an Art Form that Fights Back" Bevan Arps (bevan.arps@actfs.co.nz) Senior OO Analyst, ACT Financial Systems This communication is confidential to ACT Financial Systems (Asia Pacific) and is intended for use only by the addressee. The views and opinions expressed in this email are the senders own and do not represent the views and opinions of ACT Financial Systems (Asia Pacific). --=====================_90223614==_.ALT Content-Type: text/html; charset="us-ascii" At 14:23 16/08/2001 -0700, Sanjay Bhatia wrote:

I'm interested in seeing examples of buildfiles that work well for you and
those that you would consider very well organized. If you have copyright and
NDA issues to deal with please ignore this. Feel free to email me directly.

There are some confidentiality issues which mean I don't feel comfortable with releasing the files directly. I can describe some details however.

We've factored out a number of utility targets into a common file (Common.xml) which is included in all our other files using a standard XML trick involving entity definitions. (Search the archive for details).

The targets within each file are systematically named. For example, we've termed each collection of related builds a "block".

Inside block.ant you will find these targets:

block.build.nnnnn - Do a production build of this block at version nnnnn
block.src.nnnnn - Retrieve all the source code of this block at version nnnnn
block.compile - compile the source code for this block
block.document - document the source code for this block
block.src.files - fileset listing all source directories

This structure makes it easy to manage file maintenance.

Eg: to add a new version of the block, we don't have to guess the names of the targets required. Invoking builds in other blocks (eg for core functionality) is easy because all blocks use the same system.

Feel free to ask questions and I'll answer the best I can.

Hope this helps,
Bevan

"Programming is an Art Form that Fights Back"

Bevan Arps (bevan.arps@actfs.co.nz)
Senior OO Analyst, ACT Financial Systems

This communication is confidential to ACT Financial Systems (Asia Pacific) and is intended for use only by the addressee. The views and opinions expressed in this email are the senders own and do not represent the views and opinions of ACT Financial Systems (Asia Pacific).

--=====================_90223614==_.ALT--