Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 34133 invoked from network); 7 May 2002 17:06:33 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 May 2002 17:06:33 -0000 Received: (qmail 11593 invoked by uid 97); 7 May 2002 17:06:26 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 11544 invoked by uid 97); 7 May 2002 17:06:25 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 11532 invoked by uid 98); 7 May 2002 17:06:25 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) From: "Greg Hassan" To: "Ant Users List" Subject: Automating builds using ANT and StarTeam Date: Tue, 7 May 2002 11:06:02 -0600 Message-ID: <00bf01c1f5e9$77aa9e60$b9a1a8c0@ed.netlinx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01C1F5B7.2D102E60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <028701c1f5e1$2c97b0f0$6401a8c0@darden.virginia.edu> Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------=_NextPart_000_00C0_01C1F5B7.2D102E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Our current repository (StarTeam) is poorly organized and makes it almost impossible to automate our builds. Our product is divided into three separate packages, each one distributed as two JARs (one source code, and one for classes). I would like to separate our test code, non-code resources (i.e. PDF documents) and unused code from production code. Below is an example of the structure I am considering: --- BEGIN DIAGRAM ---- projectx implementation production package-A subpackage-A1 src subpackage-A2 src package-B subpackage-B1 src testing package-A subpackage-A1 src subpackage-A2 src package-B subpackage-B1 src unused package-A subpackage-A1 src subpackage-A2 src package-B subpackage-B1 src --- END DIAGRAM ---- the build should result in 6 jar files created: package-A.jar, package-A-src.jar package-B.jar, package-B-src.jar package-c.jar, package-c-src.jar Can anyone provide feedback and illustrate benefits and drawbacks to the above solution? Thanks. Greg ------=_NextPart_000_00C0_01C1F5B7.2D102E60--