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 <[email protected]> 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) <[email protected]> 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) > >
