lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: lucene cutomized indexing
Date Tue, 20 Jul 2004 17:40:28 GMT
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.

> 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 :)

> 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 


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

View raw message