I'm in favor of this proposal. PoCing a Java implementation in the current setup is painful. CI builds will always fail, and PRs cannot merge before releasing a new parquet-format jar.
Best, Gang On Tue, Jul 21, 2026 at 8:46 PM Antoine Pitrou <[email protected]> wrote: > Le 21/07/2026 à 14:05, Andrew Lamb a écrit : > > As a maintainer of arrow-rs 's Parquet implementation, my experience has > > been that our copy of parquet.thrift (rather than a dependency) has > worked > > great, and we have never had an issue with this scheme that I can > remember > > We do the same in Arrow C++ and never had any problem with it either. > > Regards > > Antoine. > > > > > > Andrew > > > > On Tue, Jul 21, 2026 at 7:19 AM Divjot Arora via dev < > [email protected]> > > wrote: > > > >> Hi folks, > >> > >> The parquet-java project currently declares a dependency on a pinned > >> version of parquet-format and dynamically pulls in the parquet.thrift > file > >> for the pinned version. > >> This makes it impossible to validate and merge PRs to support new > features > >> that have been merged into parquet-format but are not yet part of an > >> official parquet-format > >> release (https://github.com/apache/parquet-java/pull/3610 is an > example). > >> In contrast, the arrow-rs and arrow-cpp projects have a vendored copy of > >> parquet.thrift in their > >> repos, which allows them to bypass this problem. What do folks think > about > >> adopting this vendored approach in parquet-java? > >> > >> -- Div Arora > >> > > > > >
