lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wang <>
Subject Re: lucene cutomized indexing
Date Tue, 20 Jul 2004 18:10:11 GMT
On Tue, 20 Jul 2004 13:40:28 -0400, Erik Hatcher
<> wrote:
> On Jul 20, 2004, at 12:12 PM, John Wang wrote:
> >      There are few things I want to do to be able to customize lucene:
> >
> [...]
> >
> > 3) to be able to customize analyzers to add more information to the
> > Token while doing tokenization.
> I have already provided my opinion on this one - I think it would be
> fine to allow Token to be public.  I'll let others respond to the
> additional requests you've made.

Great, what processes need to be in place before this gets in the code base? 
> > Oleg mentioned about the HayStack project. In the HayStack source
> > code, they had to modifiy many lucene class to make them non-final in
> > order to customzie. They make sure during deployment their "versions"
> > gets loaded before the same classes in the lucene .jar. It is
> > cumbersome, but it is a Lucene restriction they had to live with.
> Wow - I didn't realize that they've made local changes.  Did they post
> with requests for opening things up as you have?  Did they submit
> patches with their local changes?
> > I believe there are many other users feel the same way.
> Then they should speak up :)

Well, I AM speaking up. So have some other people in earlier emails.
But alike me, are getting ignored. The HayStack changes were needed
specifically due to the fact that many classes are declared to be
final and not extensible.

> > If I write some classes that derives from the lucene API and it
> > breaks, then it is my responsibility to fix it. I don't understand why
> > it would add burden to the Lucene developers.
> Making things extensible for no good reason is asking for maintenance
> troubles later when you need more control internally.  Lucene has been
> well designed from the start with extensibility only where it was
> needed in mind.  It has evolved to be more open in very specific areas
> after careful consideration of the performance impact has been weighed.
>  "Breaking" is not really the concern with extensibility, I don't
> think.  Real-world use cases are needed to show that changes need to be
> made.

I thought I gave many "real-world use cases" in the previous email.
And evidently also applies to the Haystack project. What other
information do we need to provide?

I don't want to diverge from the Lucene codebase like Haystack has
done. But I may not have a choice.



>        Erik
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message