Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 53554 invoked from network); 2 Nov 2002 18:58:22 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Nov 2002 18:58:22 -0000 Received: (qmail 10276 invoked by uid 97); 2 Nov 2002 18:59:11 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 10236 invoked by uid 97); 2 Nov 2002 18:59:10 -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 10224 invoked by uid 98); 2 Nov 2002 18:59:09 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Sat, 02 Nov 2002 13:58:07 -0500 From: Ken Gentle Subject: Re: "Elements of Ant Style": the ./lib directory In-reply-to: <3DC41880.8080900@ehatchersolutions.com> X-Sender: kengentle@mail.comcast.net To: Ant Users List Message-id: <5.1.0.14.2.20021102134912.00b04e98@mail.comcast.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <5.1.0.14.2.20021102123302.00b1e9a8@mail.comcast.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Wow, Erik, now that's service! At 01:25 PM 11/2/2002, you wrote: >Ken Gentle wrote: > >>locally. It also seems to encourage deploying and distributing these >>dependent libs, giving us yet another flavor of "DLL Hell". > >Agreed, to some extent. But have a look at Chapter 8 in our book to see >how I organize library directories such that I don't simply have an >unstructuring dumping ground called "lib". Its an organized tree of 3rd >party libraries allowing me to easily switch between library versions by >simply saying -Dstruts.version=1.1b2 for example. While I haven't (yet) gone to the level of defining a version property, this is what is spec'ed in the properties file - one or more "jars", including version information in the path (usually). >>libs. I know that I'm tired of having yet another copy of >>jaxp/xalan/xerces downloaded with every new open source project I'd like >>to use. > >Have a look at Maven. It maintains a 'lib.repo' directory and >automatically pulls down dependent libraries if you don't have them. I'd already pulled CruiseControl (and gotten it into the environment) to use as a CI engine, when I revisited Maven (prompted by a Javaworld article, maybe?) Maven looks really nice -- maybe it'll be worth the effort to switch over... >>P.P.S: Seems to be rearing its head again in the J2EE space (include all >>the dependencies in the war/ear jar). > >Yes, I have issues with the WAR/EAR thing too - I've not had success >deploying some dependencies in one place in an EAR and it seems some are >needed in both the EAR and sub-WAR's too. > >I think J2EE suffers more from DD-hell... deployment descriptors, that is. :) No argument there -- but since we're all going to be generating them with XDoclet (Ch. 14!) now, there will be a lot less pain! (My compatriot is pushing this one - I've never used it, but is has to be better than maintaining all those descriptors by hand!) > Erik > > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: ============================================================= J. Kenneth Gentle (Ken) | Phone: (610) 255-0361 Gentle Software, LLC | Email: j.kenneth.gentle@acm.org ============================================================= -- To unsubscribe, e-mail: For additional commands, e-mail: