Return-Path: Delivered-To: apmail-ant-user-archive@ant.apache.org Received: (qmail 15981 invoked by uid 500); 6 Aug 2003 16:11:42 -0000 Mailing-List: contact user-help@ant.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 user@ant.apache.org Received: (qmail 15887 invoked from network); 6 Aug 2003 16:11:41 -0000 Received: from fwick01.ex.morinda.com (HELO mail.morinda.com) (66.236.69.41) by daedalus.apache.org with SMTP; 6 Aug 2003 16:11:41 -0000 Received: from USMAIL04.morinda.com ([172.16.6.206]) by mail.morinda.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 6 Aug 2003 10:11:44 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: classpath Date: Wed, 6 Aug 2003 10:11:43 -0600 Message-ID: <783A3EE2AA17B349B869477606E922A6175EEE@USMAIL04.morinda.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: classpath Thread-Index: AcNcEqoDrzGG6G+qTLSb5LLSB3iDCwAHjWXAAABDndAAADwd4A== From: "Nathan Christiansen" To: "Ant Users List" X-OriginalArrivalTime: 06 Aug 2003 16:11:44.0062 (UTC) FILETIME=[6DBCD5E0:01C35C35] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N To help get around the "library version" problem, we will rename the = library jar files with a version number if they don't come with one. = (e.g. junit.jar becomes junit_3-8-1.jar.) We can then tell at a glance = which version of the library it is. To help get around the "conflict" problem (we had a project where the = library directory had servlet.jar and j2ee.jar, both containing the = javax.servlet.* hierarchy) we now point to the directory of our servlet = container (Tomcat) to get the jar files provided by the container. We = still have to worry about particular libraries containing the same = classes, but since we have a small number of Java developers and we = don't use different libraries that do similar things it usually isn't a = big problem. You might consider having a library czar. A single person who approves = all library dependencies. I would suggest that this person is also the = build and deploy person. -- Nathan Christiansen Tahitian Noni International http://www.tahitiannoni.com -----Original Message----- From: Keith Hatton [mailto:khatton@axiomsystems.com] Sent: Wednesday, August 06, 2003 9:50 AM To: Ant Users List Subject: RE: classpath Really it's a tradeoff between control and ease of use. We use pretty much the same technique as Nathan, and it works for the = time being. But, over time, I can see the potential for our "lib" directory to fill = up, and you lose control of which versions of what libraries are = included, and if there is any conflict (same classes in 2 jars) you have = to guess which one will be used ... so you may decide the approach of = specifying each jar is better, and live with the maintenance requirement = that comes with it. Oh dear, it sounds like another case of "no silver bullet" ... Keith -----Original Message----- From: Nathan Christiansen [mailto:Nathan_Christiansen@tni.com] Sent: 06 August 2003 16:43 To: Ant Users List We have used the following code, and it picks up all jar files in a = directory: --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For additional commands, e-mail: user-help@ant.apache.org