On Wed, Apr 8, 2009 at 14:13, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > (I assume you mean jackrabbit-text-extractors)
ah, right. sorry. > The SearchIndex class currently has a hard dependency to TextExtractor > that needs to be there also on runtime, so we can't make the > text-extractors dependency optional without changing things. I'd > prefer to replace that dependency with one to the Tika Parser > interface, but then we need a hard Maven dependency on Tika. ideally I'd like to have the parser/text-extractor dependencies optional and whoever uses jackrabbit-core needs to decide which parsers/text-extractors he wants to use (the same actually also applies to persistence managers). however, that requires that we get rid of the runtime dependencies to either Tika and/or jackrabbit-text-extractors, but I don't know how this can be done easily (without reflection hacks). > In either case I think it's best for everyone if the current > TextExtractor classes will remain in the runtime classpath (in either > the text-extractors or the core jar) so that there's no need to modify > existing configurations. OK, I agree. backward compatibility should be guaranteed for 1.6 and there shouldn't be deployment surprises with an upgrade. regards marcel
