Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 68058 invoked from network); 25 Jan 2002 15:30:09 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Jan 2002 15:30:09 -0000 Received: (qmail 22917 invoked by uid 97); 25 Jan 2002 15:29:59 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 22879 invoked by uid 97); 25 Jan 2002 15:29:58 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 22868 invoked from network); 25 Jan 2002 15:29:58 -0000 Subject: Re: Distributable JAR filename From: "Andrew C. Oliver" To: Lucene Developers List In-Reply-To: <01dd01c1a5a2$6483aa80$6401a8c0@darden.virginia.edu> References: <01b101c1a596$f7da97a0$6401a8c0@darden.virginia.edu> <1011959612.5120.3008.camel@linux2.superlinksoftware.com> <01dd01c1a5a2$6483aa80$6401a8c0@darden.virginia.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.0.99+cvs.2001.12.18.08.57 (Preview Release) Date: 25 Jan 2002 10:20:58 -0500 Message-Id: <1011972058.7095.3035.camel@linux2.superlinksoftware.com> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 2002-01-25 at 08:15, Erik Hatcher wrote: > From: "Andrew C. Oliver" > > > Most Jakarta projects currently do it differently that Lucene's current > > > procedure, so I'm not proposing anything unusual. > > > > > > > IMHO They are wrong. > > :) At least we all have our own strong opinions on this issue. > > > -1.. Yes.. Think of the situation where you have two unknown versions > > of the jar... It is very easy to cause the java version of DLL hell. > > Yet by simply looking at the jar in your classpath or web container you > > can see which one to zap or rename to mud. > > > > This doesn't solve the problem but it sure as heck makes it obvious. > > Version information can be embedded inside the JAR as a properties file or > in the manifest, so its would be easily identifiable. > > I certainly can see both sides of this issue, but my overriding thoughts are > that upgrading to a new version of Lucene should be as easy as pointing a > build to a new directory and not dealing with JAR file name changes too. I > believe classpaths should be tightly controlled and using Ant this means > that a is constructed pointing to exact JAR files (and not to include > "*.jar"). > > Suppose I have a project that is using Lucene and, of course, is using an > Ant build. How should my build be flexible enough to handle the upgrade of > a new version of Lucene without the build file itself having to be modified? > I'm curious how you handle this situation. I have a technique that I've > developed that works nicely, even with Lucene's scheme (because at least its > JAR file name is the same as distribution directory name) but it works even > nicer with JAR's named the same. > I'm not quite as familiar with POI's new Apacheized (we've adapted the same standard build as Avalon, Cocoon and other projects with minor improvements), but until recently at least we've used a command line parameter. I'll have a different opinion on this once there is *real* versioning introduced into the jar/jdk. (I could have sworn I saw a JSR on this), until then... I like knowing what I have just by looking at it. -ACO > Erik > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: For additional commands, e-mail: