+1 for all the reasons stated above. On Thu, Jul 23, 2026 at 10:21 PM Gang Wu <[email protected]> wrote:
> 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 > > >> > > > > > > > > > >
