You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "is@avik" <is...@avik.biz> on 2003/11/06 11:41:38 UTC

webfood.us

Hello,

We are proud to announce that our site www.webfood.us
is now using Lucene engine for searching thru
restaurant menus. We would like our site to be listed
in 'Powered By' section of Lucene site.

Shortly about the project. Webfood.us is NJ restaurants
directory allowing each restaurant to have their own customized
menu pages and publish products and specials. Users may find
restaurants near them, find dish or specials across all menus,
browse up-to-date menus and place online orders.
Menu is stored in xml and has flexible tree like structure
which is difficult to represent with RDBMS. Lucene suites
best our data representation. We've built Advanced
Search for sophisticated queries and every restaurant has
its own in-store menu search.
Lucene let us drop unnecessary xml->sql transformation used
previously only for search purposes.

Other then Lucene we also use many open source frameworks -
JBoss/Struts/XML/XSLT/Ant.

Great job is done with Lucene, thanks guys!

Regards,
Igor Semenko,
java developer, www.webfood.us


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


Re: [FilterIndexReader]; [build.xml] RC2 package build issues.

Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Thursday, November 6, 2003, at 09:13  AM, Gregor Heinrich wrote:\
> FilterIndexReader.FilterTermPositions.nextPosition() where the member 
> in is
> referenced. Although it actually is the same variable in a twofold
> interpretation -- inherited from FilterTermDocs and accessed via 
> enclosing
> scope also from FilterTermDocs -- the compiler frontend detects an 
> error. I
> think it would not
> be a problem for anyone to make the reference explicit by replacing
>
> ((TermPositions)in).nextPosition()
>
> by
>
> ((TermPositions)this.in).nextPosition()

Sounds like a bug you should report to Eclipse.  No error reported in 
IDEA :))

I've gone ahead and committed this change though.

	Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org


[FilterIndexReader]; [build.xml] RC2 package build issues.

Posted by Gregor Heinrich <he...@igd.fhg.de>.
Hello,

thanks for the nice release candidate RC2 of Lucene 1.3.

I have one question about the FilterIndexReader which is newly introduced in
rc2.

While the regular ant-based build works fine, my IDE (Eclipse R2.1.1) keeps
complaining about the method
FilterIndexReader.FilterTermPositions.nextPosition() where the member in is
referenced. Although it actually is the same variable in a twofold
interpretation -- inherited from FilterTermDocs and accessed via enclosing
scope also from FilterTermDocs -- the compiler frontend detects an error. I
think it would not
be a problem for anyone to make the reference explicit by replacing

((TermPositions)in).nextPosition()

by

((TermPositions)this.in).nextPosition()

.

Further, thanks for the changes in build.xml. This actually reflects a more
seemless variant that is usable stand-alone as well as in IDEs such as
Eclipse (see older mails on this topic in the lucene lists).

As a suggestion: The clean target does not sweep the javacc outputs from the
source files. This should be in especially if someone works on the jj files.

Regards, Gregor


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org