turns out there's no code there, it's just shading. so parquet-variant has to be its home.
we just need to keep jackson out as a requirement variants to work at all. I think it's also to have the shaded jackson as the library used, so other jackson versions don't step on things On Mon, 20 Apr 2026 at 09:44, Gang Wu <[email protected]> wrote: > Both approaches seem inelegant. If we must choose one, I'm inclined to put > it in parquet-jackson. > > On Thu, Apr 9, 2026 at 8:13 PM Steve Loughran <[email protected]> wrote: > > > I was thinking the parquet-jackson module is the right home > > > > 1. It's a point of integration between json and parquet > > 2. if you don't depend on that, you don't have to worry about jackson > > CVE reports > > > > But looking at the module, parquet-jackson simply generates a shaded > > jackson library: there's no code there. parquet-variant is the only place > > for it. > > > > > > > > On Wed, 8 Apr 2026 at 19:02, Andrew Lamb <[email protected]> wrote: > > > > > (Sending this on behalf of the author) > > > > > > I'm working on [PR #3415] (GH-3414) which adds a parseJson method to > > > VariantBuilder for JSON-to-Variant conversion. During review, > > > @steveloughran raised a good question about where the JSON parsing > logic > > > should live, and suggested bringing it to the dev list. > > > > > > > > > > > > Currently, VariantJsonParser is in the parquet-variant module. This > > > requires adding jackson-core as a compile-scope dependency (for > > > JsonFactory, JsonParser, StreamReadConstraints, etc.) alongside > > > parquet-jackson at runtime scope — the same pattern used by > > > parquet-hadoop. > > > > > > > > > > > > Steve suggested moving VariantJsonParser into parquet-jackson > instead. > > > > > > > > > > > > Option A: Keep in parquet-variant (current approach) > > > > > > > > > - Keeps all variant logic in one module > > > - Follows the existing parquet-hadoop pattern for Jackson > dependencies > > > > > > > > > - Requires jackson-core at compile scope + parquet-jackson at runtime > > > scope > > > > > > > > > > > > Option B: Move to parquet-jackson > > > - Avoids adding Jackson compile dependency to parquet-variant > > > > > > > > > - parquet-jackson already has unshaded Jackson internally, so no > > > dependency issue > > > > > > - Requires parquet-jackson to depend on parquet-variant (for > > > VariantBuilder, Variant, etc.) > > > - No build cycle as far as I can tell — parquet-variant doesn't > > currently > > > depend on parquet-jackson at compile scope > > > > > > > > > > > > [PR #3415]: https://github.com/apache/parquet-java/pull/3415 > > > > > >
