[
https://issues.apache.org/jira/browse/TIKA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095574#comment-18095574
]
ASF GitHub Bot commented on TIKA-4775:
--------------------------------------
tballison commented on PR #2946:
URL: https://github.com/apache/tika/pull/2946#issuecomment-4946118449
On the point about pdfbox core in the xmp module, I struggled with the right
option. I did a bakeoff with 15k xmps, and pdfbox's date parser won over
jempbox. We could copy/paste the date utils from pdfbox?
Agent summarizes:
```
The observation is correct, but this was a
deliberate, discussed decision — pdfbox's DateConverter beat jempbox 99.8%
vs 99.2% (and 224 wrong) in a 15k-date
bake-off, and you explicitly chose "just add pdfbox-core." If we want to
trim it later, extracting only
DateConverter is an option, but it's an accepted tradeoff, not a bug
```
@THausherr any recommendations? The issue is that we're adding a dependency
on pdfbox to xmp-commons _only_ for the date parser. It basically doesn't
matter for tika-app or tika-server or grpc because they all bring in
tika-parsers-standard which already has pdfbox. The only effect it has is on
users who want to subselect a few of the standard parser modules that don't
include pdf parsing. I'd guess this user base is tiny, but I don't know.
> Experiment unifying xmp parsing in 4.x
> --------------------------------------
>
> Key: TIKA-4775
> URL: https://issues.apache.org/jira/browse/TIKA-4775
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Minor
>
> We parse xmp at least 3 different ways currently, and we're basing what keys
> we're looking for based on the container file mime type. We should normalize
> xmp parsing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
