Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 60970 invoked from network); 11 Feb 2002 19:42:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 11 Feb 2002 19:42:35 -0000 Received: (qmail 6164 invoked by uid 97); 11 Feb 2002 19:42:38 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 6144 invoked by uid 97); 11 Feb 2002 19:42:37 -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 6133 invoked from network); 11 Feb 2002 19:42:37 -0000 Message-ID: <502326F46B08D41191C400508B6D70C10235CBAA@ThisAddressDoesNotExist> From: Les Hughes To: 'Lucene Developers List' Subject: RE: [SUBMIT] docweb demo app Date: Mon, 11 Feb 2002 19:40:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sorry to come a bit late to the party...Two things 1) Thanks for the Ant task - that'll save me some time on the train tomorrow ;-) 2) Maybe I need to RTFM but does the index run straight out of the WAR file? I was thinking about creating a WARDirectory to do this but if it's possible some other way I'd be interested to hear. Les. P.S. Maybe I'll have to wait for the commit to get my hands on the code...hint hint!! > -----Original Message----- > From: Erik Hatcher [mailto:lists@ehatchersolutions.com] > Sent: 11 February 2002 04:32 > To: Lucene Developers List > Subject: [SUBMIT] docweb demo app > > > Lucene-dev, > > Attached is the recently discussed Ant task code and > the patches > necessary to build a web application containing an index of Lucene's > documentation (the docs in CVS and the generated Javadocs). > > Its certainly not perfect, and no doubt is in need of > refactoring, but if I > waited until it was completely polished it'd never see the > light of day! > > I patched into build.xml such that I took advantage of the > existing web > application so as to get it developed quickly. My actual > application uses > Struts for the web app, and that is of course a bit too heavy > to toss into > this demo, especially the first pass. > > One change to configuration.jsp is required (and since this > would typically > be changed in the other demo web app, perhaps it can be > modified to this in > CVS or cloned for this demo app, or use a filtered > with a token in > configuration.jsp): > String indexLocation = > getServletContext().getRealPath("/WEB-INF/index"); > > This is a proof-of-concept, and the build and web app will need some > polishing. But it works "out of the box" with the patches > applied (see the > docweb-patches.txt file in the .zip attached). > > To build, simply run the docweb-war target: > > ant docweb-war > > it churns for a bit on indexing the documentation (but not > long), and there > will then be a bin/docweb/lucenedocweb.war file (mine was > about 2MB in size > because of the embedded index). > > Here are some known issues (the ones I can think off the top > of my head): > > - It hooks into the existing demo web app pages, so searching > works, but the > results page is broken because its not adding the same fields > the original > demo expects. Again, this is proof-of-concept that a web app > demo can be > delivered that is fully functional with an embedded index and > does something > useful with Lucene's docs. > > - The task does some dependency checking, but after > seeing the 'uid' > features in the Lucene demo code more closely I can see that > it needs to be > refactored to take advantage of this kind of thing. > > - How should file content be handled? Embedded in the index as > "rawcontents"? Copied to a directory inside the WAR statically? Its > currently being embedded, which has its share of issues, as > would copying > also. > > - I'm still a "newbie" to Lucene's API. I built this thing > with very little > effort (thanks lucene-dev!) several months ago, and haven't > really touched > it since as its not the direct focus of my current work. It > has simply > worked solidly since built, so I haven't had a need to dig > into it more to > clean it up or tweak it. There is of course much work to be > done to have a > really solid task, but I feel this is a good start. > > Let me know if there are any questions or problems with > incorporating this. > And like I mentioned before, I'm looking for expert eyes at > IndexTask code > to make it the best it can be. Folks that contribute to it will earn > acknowledgements in my upcoming Ant book for sure (if you > desire, certainly > wouldn't print anyone's name without permission). > > Think about Gump or some other process indexing all of Jakarta's docs > (perhaps during release builds only?) with fields for > product, version, etc. > Wow! There is already a Jakarta search engine, but I'm sure > it doesn't hold > a candle to Lucene's capabilities. I feel that building an > index of static > content during an Ant build is an important capability for > Lucene to have - > docs are typically static until the next release, so it makes > sense to index > them at build time, right? > > Comments, suggestions, criticisms, etc all are welcome. > > Erik > > > -- To unsubscribe, e-mail: For additional commands, e-mail: