Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 43186 invoked from network); 3 Jan 2005 17:54:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 3 Jan 2005 17:54:55 -0000 Received: (qmail 38438 invoked by uid 500); 3 Jan 2005 17:54:27 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 38233 invoked by uid 500); 3 Jan 2005 17:54:23 -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 38211 invoked by uid 99); 3 Jan 2005 17:54:23 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from p15112568.pureserver.info (HELO p15112568.pureserver.info) (217.160.91.29) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 03 Jan 2005 09:54:16 -0800 Received: from [192.168.10.103] (ppp-62-245-161-4.mnet-online.de [62.245.161.4]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p15112568.pureserver.info (Postfix) with ESMTP id A9FA614010F for ; Mon, 3 Jan 2005 18:54:12 +0100 (CET) Message-ID: <41D986BD.6090305@apache.org> Date: Mon, 03 Jan 2005 18:54:05 +0100 From: Bernhard Messer User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Lucene Developers List Subject: Re: CFS file and file formats References: <20041230161754.76557.qmail@web12702.mail.yahoo.com> <41D55489.70703@apache.org> <41D98408.3030900@apache.org> In-Reply-To: <41D98408.3030900@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Doug Cutting schrieb: > Bernhard Messer wrote: > >>> I understand the technical reason for main() there, but logically this >>> belongs to an external utility class, I think. >>> >> Otis you are right, i already thought about it. It could be simply >> moved to a newly created class in org.apache.lucene.util package. But >> then we have to change the visibility of CompoundFileReader to >> public. I have no problems with a public CompoundFileReader class. >> Does anybody see a reason that the visibility of CompoundFileReader >> should not be changed to public ? > > > Yes. Historically we've tried hard in Lucene to not make things > public unless they're useful to users. We try to keep the public API > as small as possible. This makes the documentation easier to read and > also makes the system easier to maintain. CompoundFileReader is an > implementation class, not a user class. > Why not implementing a small utility class, f.e CompoundFileUtil.java within the org.apache.lucene.index Package ? This class could be public and implement the necessary functionality. This is what i would prefer, because we don't have to change the visibility of CompoundFileReader or other parts of the API. The other option would be to add a public static method to IndexReader class. But i don't like to overwhelm IndexReader with a method, just a very small audience would use. Bernhard > > --------------------------------------------------------------------- > To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org > For additional commands, e-mail: lucene-dev-help@jakarta.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org