Mixed option based on past experience with other projects good: you can share your testing tools/libraries bad: you are now making a commitment to keep them stable. Things like the move to junit 5, to assertj etc will break downstream stuff.
if it is done, publish it with a "no stability guarantees use at own risk" warning. People will still complain after a breaking change, because the more stability you unintentionally provide, the more downstream users unintentionally rely on it. On Wed, 22 Jul 2026 at 15:59, Aaron Niskode-Dossett via dev < [email protected]> wrote: > On Wed, Jul 22, 2026 at 4:04 AM Ismaël Mejía <[email protected]> wrote: > > > > > > > > > * - I tried to downstream the dependency into Apache Spark with success > > (Notice that it now requires some additional dependencies exclusions > > because Parquet 1.18.0 moved to junit 5 which conflicts with Spark's > Junit > > Jupiter platform).* > > > > This caught my eye from the voting thread. Spark depends on some parquet > test jars [1], which naturally pull in whatever test framework we use. An > alternative would be for us to publish an artifact like > `parquet-test-support` containing useful code for partner projects to write > their tests with. At least some of the components Spark uses from the test > jar (like MemPageStore) seem quite reasonable to share publicly. > > If anyone else thinks this would be useful I can carve out some time (okay, > some codex cycles) and create a PR for that. > > Thanks! -- Aaron > > [1] > > https://github.com/apache/spark/blob/edadb008523340f5f3a0c37a7b634f570837a6ef/sql/core/pom.xml#L140-L161 > > -- > Aaron Niskode-Dossett, Data Engineering -- Etsy >
