You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tika.apache.org by "Tim Allison (Jira)" <ji...@apache.org> on 2025/12/04 22:42:00 UTC
[jira] [Created] (TIKA-4554) Remove the ForkParser in 4.x
Tim Allison created TIKA-4554:
---------------------------------
Summary: Remove the ForkParser in 4.x
Key: TIKA-4554
URL: https://issues.apache.org/jira/browse/TIKA-4554
Project: Tika
Issue Type: Task
Reporter: Tim Allison
In 3.x, we had four different ways to fork a process to handle dangerous files:
a) tika-batch
b) tika-server
c) tika-pipes
d) fork parser
For 4.x, we should centralize/unify our forking through tika-pipes if possible.
We've already removed tika-batch on TIKA-4333. We removed the full server forking as part of the enormous refactoring on TIKA-4545.
Let's remove the ForkParser from 4.x. I propose that if anyone needs it, we can write a light wrapper around tika-pipes that would take an InputStream, write it to a temp file and then run tika-pipes against the file.
Any objections?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [jira] [Created] (TIKA-4554) Remove the ForkParser in 4.x
Posted by Tim Allison <ta...@apache.org>.
Absolutely. Thank you. We have several more 3.x releases for
deprecating what we're removing in 4.x. Given the number of changes in
4.x, we should probably keep supporting 3.x for at least 6 months
after the 4.0.0 release? Aim for a 4.0.0-ALPHA release beginning of
January?
On Sun, Dec 7, 2025 at 8:08 AM Nicholas DiPiazza
<ni...@gmail.com> wrote:
>
> Do we want to deprecate it for 1 release? and then in the javadoc provide a
> reference to the replacement?
>
> On Thu, Dec 4, 2025 at 4:42 PM Tim Allison (Jira) <ji...@apache.org> wrote:
>
> > Tim Allison created TIKA-4554:
> > ---------------------------------
> >
> > Summary: Remove the ForkParser in 4.x
> > Key: TIKA-4554
> > URL: https://issues.apache.org/jira/browse/TIKA-4554
> > Project: Tika
> > Issue Type: Task
> > Reporter: Tim Allison
> >
> >
> > In 3.x, we had four different ways to fork a process to handle dangerous
> > files:
> >
> > a) tika-batch
> >
> > b) tika-server
> >
> > c) tika-pipes
> >
> > d) fork parser
> >
> >
> >
> > For 4.x, we should centralize/unify our forking through tika-pipes if
> > possible.
> >
> > We've already removed tika-batch on TIKA-4333. We removed the full server
> > forking as part of the enormous refactoring on TIKA-4545.
> >
> > Let's remove the ForkParser from 4.x. I propose that if anyone needs it,
> > we can write a light wrapper around tika-pipes that would take an
> > InputStream, write it to a temp file and then run tika-pipes against the
> > file.
> >
> >
> >
> > Any objections?
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.20.10#820010)
> >
Re: [jira] [Created] (TIKA-4554) Remove the ForkParser in 4.x
Posted by Nicholas DiPiazza <ni...@gmail.com>.
Do we want to deprecate it for 1 release? and then in the javadoc provide a
reference to the replacement?
On Thu, Dec 4, 2025 at 4:42 PM Tim Allison (Jira) <ji...@apache.org> wrote:
> Tim Allison created TIKA-4554:
> ---------------------------------
>
> Summary: Remove the ForkParser in 4.x
> Key: TIKA-4554
> URL: https://issues.apache.org/jira/browse/TIKA-4554
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
>
>
> In 3.x, we had four different ways to fork a process to handle dangerous
> files:
>
> a) tika-batch
>
> b) tika-server
>
> c) tika-pipes
>
> d) fork parser
>
>
>
> For 4.x, we should centralize/unify our forking through tika-pipes if
> possible.
>
> We've already removed tika-batch on TIKA-4333. We removed the full server
> forking as part of the enormous refactoring on TIKA-4545.
>
> Let's remove the ForkParser from 4.x. I propose that if anyone needs it,
> we can write a light wrapper around tika-pipes that would take an
> InputStream, write it to a temp file and then run tika-pipes against the
> file.
>
>
>
> Any objections?
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>