tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TIKA-2882) Parsers should not include HTTP client code
Date Fri, 16 Aug 2019 14:55:00 GMT

    [ https://issues.apache.org/jira/browse/TIKA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909101#comment-16909101

Sergey Beryozkin commented on TIKA-2882:

Hi Tim

Can we consider giving it a go ? Bob agrees to focus on the modules only, so all we have to
do to get it started is to create few modules grouping the specific parsers, and have the
existing tika-parsers incorporating those new modules. There should be no even coding involved
unless I'm missing something. If you can create a quick PR only and then I can test it with
Quarkus, etc, what do you think ?

> Parsers should not include HTTP client code
> -------------------------------------------
>                 Key: TIKA-2882
>                 URL: https://issues.apache.org/jira/browse/TIKA-2882
>             Project: Tika
>          Issue Type: Improvement
>          Components: parser
>    Affects Versions: 1.21
>            Reporter: Jonathan Essex
>            Priority: Major
> Folks, does it really make sense for a parser to have a REST client built in?
> The GROBID and NLTKNERecogniser parsers use the apache CXF client directly. 
> Since I don't use CXF and my entire app is built on a different JAX-RS stack this just
dropped me straight into dependency hell.
> Surely it would make more sense to keep the parsers... well, parsers... and build support
for delegating parsing to other services into some higher level in the stack (such as the
server, where the CXF dependency is more benign). 

This message was sent by Atlassian JIRA

View raw message