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

Reply via email to