Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 23922 invoked from network); 1 Dec 2001 03:17:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Dec 2001 03:17:35 -0000 Received: (qmail 21120 invoked by uid 97); 1 Dec 2001 03:17:43 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 21103 invoked by uid 97); 1 Dec 2001 03:17:42 -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 21092 invoked from network); 1 Dec 2001 03:17:42 -0000 Message-ID: <011c01c17a16$ba07ff40$6401a8c0@darden.virginia.edu> From: "Erik Hatcher" To: "Lucene Developers List" References: <4BC270C6AB8AD411AD0B00B0D0493DF0EE7D48@mail.grandcentral.com> Subject: Re: Contributor Document class repository proposal Date: Fri, 30 Nov 2001 22:17:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Doug Cutting" > I like the proposal, but I am not sure that Jakarta should host the > contributions. That starts to imply that they're a part of the Lucene > project, and might be supported by it, etc. Ant has a ton of "optional" tasks that it hosts and maintains. Some are genuinely useful to all, and others are a pain for the ant-dev team to maintain because they themselves don't use them or the API's they are built-upon. > Is that okay? Is there an important reason that you think these > contributions should be hosted by Jakarta? So certainly lucene-dev should be cautious about what the fold in, but by including very common Document generators as part (as an optional download) of the Lucene offering it makes it even easier for folks to come up to speed with it and integrate it into their world. Something that builds a Document from a text file is a good candidate (although the demo FileDocument suffices), and of course everyone and their brother wants to index HTML files, and of course XML. PDF is hot. MS Word would be awesome (anyone done this?). Folks would salivate just to be able to download Lucene and point it at a directory tree and have it indexed without having to write any code - and only when they needed something custom would they then dig deeper and learn its API. Folks don't to know how to develop Ant tasks to make it work for them - just as an analogy. Struts - now thats somewhat of a different story! :) > Of course some contributions should be added directly to Lucene. I'm > hesitant to add contributions that require libraries that Lucene is not > already dependent on, or that are not included in the standard JDK. Yes, dependencies are tricky to deal with in this environment, but expected. By utilizing in Ant you could conditionally turn on/off the compilation of code in the 'contrib' area without anyone being hassled - if they want to build something specific, they have to know to get the dependency stuff. Lucene's nightly build with Gump could easily have dependencies like JTidy added to it. Thats the end of my sales pitch to get 'contrib' added to Lucene's CVS! :) I'm happy we've gotten the positive response that has been received so far.... Lucene rocks. Erik -- To unsubscribe, e-mail: For additional commands, e-mail: