JiriOndrusek opened a new pull request, #9078:
URL: https://github.com/apache/camel-quarkus/pull/9078
Fixes #9076. Add tika and docling parsers to the ingestion pipelines
* Adds an optional per-pipeline, build-time parser option (tika | docling)
that turns binary payloads (PDF, office, HTML) into text before splitting —
tika extracts in-process, docling produces markdown via a Docling Serve
instance. Stacked on #9039's PR.
* The PR also refactors the route generation around the new parse stage,
splitting the grown IngestRoutes into focused classes so each route topology
reads as a single narrative chain.
Architecture:
- The parse step slots between the consumer and the ingestion engine,
identically for both route topologies (watched directory and consumer-fed
endpoint).
- Route generation now has one creation path for both declaration styles
(properties and @Ingest builder), producing a PipelineSpec and dispatching to
one of two route topologies. IngestRoutes keeps only that narrative; step
factories live in IngestSteps, the parse stage in IngestParsers, bean
resolution in IngestBeanResolver.
- A parsed document is treated as untrusted input: its identity is
captured before the parse, and the payload cannot influence parser behavior via
headers or charset heuristics.
- Native support covers the Tika PDF recipe (scoped angus-activation
feature exclusion, PDFBox runtime initialization + resources);
tika-parser-pdf-module is BOM-managed.
- Build-time validation rejects unknown parsers and missing parser
components, naming the artifact to add; covered by deployment tests and
JVM+native ITs for both parsers and both topologies.
<!-- Uncomment and fill this section if your PR is not trivial
[ ] An issue should be filed for the change unless this is a trivial change
(fixing a typo or similar). One issue should ideally be fixed by not more than
one commit and the other way round, each commit should fix just one issue,
without pulling in other changes.
[ ] Each commit in the pull request should have a meaningful and properly
spelled subject line and body. Copying the title of the associated issue is
typically enough. Please include the issue number in the commit message
prefixed by #.
[ ] The pull request description should explain what the pull request does,
how, and why. If the info is available in the associated issue or some other
external document, a link is enough.
[ ] Phrases like Fix #<issueNumber> or Fixes #<issueNumber> will auto-close
the named issue upon merging the pull request. Using them is typically a good
idea.
[ ] Please run mvn process-resources -Pformat (and amend the changes if
necessary) before sending the pull request.
[ ] Contributor guide is your good friend:
https://camel.apache.org/camel-quarkus/latest/contributor-guide.html
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
