[...]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 made.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
