From lucene-dev-return-8518-apmail-jakarta-lucene-dev-archive=jakarta.apache.org@jakarta.apache.org Thu Dec 09 01:36:32 2004 Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 97368 invoked from network); 9 Dec 2004 01:36:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 9 Dec 2004 01:36:31 -0000 Received: (qmail 49323 invoked by uid 500); 9 Dec 2004 01:36:28 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 49292 invoked by uid 500); 9 Dec 2004 01:36:27 -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 49272 invoked by uid 99); 9 Dec 2004 01:36:27 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of janssen@parc.com designates 13.1.64.93 as permitted sender) Received: from alpha.Xerox.COM (HELO alpha.xerox.com) (13.1.64.93) by apache.org (qpsmtpd/0.28) with SMTP; Wed, 08 Dec 2004 17:36:26 -0800 Received: from synergy1.parc.xerox.com ([13.1.101.60]) by alpha.xerox.com with SMTP id <150610(1)>; Wed, 8 Dec 2004 17:36:15 PST Received: from parc.com ([127.0.0.1]) by synergy1.parc.xerox.com with SMTP id <58617>; Wed, 8 Dec 2004 17:36:15 PST To: "Lucene Developers List" Subject: Re: two versioning problems with Lucene In-Reply-To: Your message of "Tue, 07 Dec 2004 17:53:20 PST." Date: Wed, 8 Dec 2004 17:36:07 PST From: Bill Janssen Message-Id: <04Dec8.173615pst."58617"@synergy1.parc.xerox.com> X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > I'd like to hear others weigh in on this repackaging issue. Is this a > common practice? The usual problem I see is that the user wants a single-file "double-clickable" application packaged as a jar file. So you unpack the subsidiary jars, usually libraries like Lucene or Simple, and then build a new jar file which contains all the classes of the various unpacked jars, with a Makefile line like this: ${JAR} uf $@ `find . -name \*.class` Since all the META-INF/MANIFEST.MF files wind up in the same place during unpacking of the various jar files, only the information in the last one unpacked is preserved, but the user typically builds their own jar manifest anyway. I agree with you that a careful user might (and perhaps should) put the right stuff in their jar manifest, but I'm not sure I want to depend on it. I've seen this in a number of places, but that may just be my experience. Bill --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org