[
https://issues.apache.org/jira/browse/TIKA-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16850808#comment-16850808
]
Jonathan Essex commented on TIKA-2882:
--------------------------------------
OK, I do very much like tika-parser-modules - now that I know about it! I'm
trying to do a local build right now...
It strikes me that tika-core and tika-parser-modules could perhaps be bought to
maturity ahead of a full 2.0 release? This would allow people (like me) who are
primarily interested in the APIs to reap the benefits of modularity without
waiting for other components such as tika-server to catch up.
Would managing tika-core and tika-parser-modules as submodules in git make it
easier to temporarily 'detach' the release cycle of these elements from the
mothership and so accelerate this approach? This would be better than trying to
drip-feed 2.x enhancements into 1.x, I feel.
> 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
(v7.6.3#76005)
