Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 58613 invoked by uid 500); 17 Oct 2001 02:53:55 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 58604 invoked from network); 17 Oct 2001 02:53:55 -0000 Date: Tue, 16 Oct 2001 19:48:05 -0700 (PDT) From: "Craig R. McClanahan" Sender: To: Subject: Re: failure notice (fwd) In-Reply-To: <032901c156b6$0b3761a0$6a16a643@intalio.com> Message-ID: <20011016194056.F35043-100000@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 16 Oct 2001, Remy Maucherat wrote: > Date: Tue, 16 Oct 2001 19:47:21 -0700 > From: Remy Maucherat > Reply-To: tomcat-dev@jakarta.apache.org > To: tomcat-dev@jakarta.apache.org > Subject: Re: failure notice (fwd) > > > Sign ... sometimes 100k is too small. > > > > I just did a pretty good-sized commit to switch our XML parsing activity > > over to the Digester package from jakarta-commons, with a very noticeable > > improvement in startup performance. Here's the summary of the changes. > > It does seem faster indeed. > > Would it be acceptable if we just committed the appropriate version of each > library in the CVS ? > Thay're small, and there's 3 of them ... > In case anybody doesn't know how I feel about JARs in CVS ... YUCK. :-) IMHO, it's not an issue of size, or even where they come from. JARs in CVS cause people to lose track of what they really depend on, and (more particularly) the *version* of things you depend on. It just gets worse when you check in things that were built from mutually-incompatible common dependents. If Gump has taught us anything, this should be one of the key insights. And, if you've ever tried to update jakarta-site2, or other repositories that store lots of JARs, when you're dialed in at 56k you won't think much of the idea either. Besides, quick-and-easy grabbing of dependencies was what the so-far-incomplete CJAN/JJAR/whatever type projects were supposed to solve. I'd prefer to wait for the real solution. > Remy > > Craig (who's thinking about ways to get out of the circular dependency trap on the JARs we already have checked in)