Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.218.164 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type
         :content-transfer-encoding;
        b=xDH0Sr+sJRqaJOqWvyULYawhx/eO27zpdJb67DbD4RcJ+aB/xyd62fV1uOUmjopn00
         df/5BNaa3oLQxRLe0GnLOvs1LuCYJekfN00LmgIfUA/Ih/jMwWvvD7kw1eZLSJzFYzpf
         f9eBoJLrOR+OxeEn3GGLtZR+PzNP1NFSW1l+M=
MIME-Version: 1.0
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Tue, 7 Apr 2009 23:29:06 +0200
Message-ID: <510143ac0904071429u73de9193oc0a0fb431d24eace@mail.gmail.com>
Subject: Getting rid of jackrabbit-text-extractors
To: Jackrabbit Developers <dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi,

JCR-1878 is now resolved and Jackrabbit trunk is depending on Apache
Tika for text extraction functionality. Thus there is little more need
for jackrabbit-text-extractors as a standalone component. Anyone who
needs that functionality separately from jackrabbit-core should just
go for Tika directly.

For backwards compatibility with existing configurations (and
potential extensions) we still need the current
org.apache.jackrabbit.extractor classes, but I'm thinking of simply
moving the entire package to jackrabbit-core and deprecating
everything except the new Tika-based extractor. In fact I'd even go as
far as changing the indexing code in jackrabbit-core to use the Tika
Parser interface directly and only provide a backwards-compatibility
layer for the TextExtractor classes we have.

Thus Jackrabbit 1.6 would no longer contain a separate text-extractors
jar, but all the existing TextExtractor classes would still be
incluced. In Jackrabbit 2.0 we'd drop all the TextExtractors and only
use Tika Parsers.

BR,

Jukka Zitting