Hi all,
I'd like to open a discussion on adding a standalone Beeline distribution to the Hive release, and on distributing it through Homebrew (macOS) and Scoop (Windows). This is the ongoing work under HIVE-29821. *Legal review outcome* We initially explored bundling a JRE with the installer (via jpackage), but Legal review concluded we can't redistribute an OpenJDK build alongside our own ASF artifacts under the current release policy. The Homebrew and Scoop route resolves this cleanly: both package managers support declaring a JRE as an install-time dependency (openjdk@21 for brew, java/temurin21-jre for scoop) rather than shipping one. The user's package manager fetches the JRE from its own trusted source at install time; the Hive release contains only the fat jar plus its aggregated LICENSE/NOTICE. *Proposal* 1. Publish a new release artifact apache-hive-beeline-<version>-standalone.jar — a self-contained shaded fat jar produced by the hive-beeline module. It runs on any JRE 21+ with a single java -jar, no Hadoop installation required. 2. Have this jar uploaded to the ASF mirror alongside the existing release artifacts, at: https://downloads.apache.org/hive/hive- <version>/apache-hive-beeline-<version>-standalone.jar with .asc and .sha512 sidecars. The tarball artifacts stay as they are today; this is purely additive. 3. Provide Homebrew formula and Scoop manifest that install this jar as apache-hive-beeline on macOS and Windows, giving users a beeline command on their PATH. This is what other ASF projects do. apache-spark, kafka, maven, and zookeeper all live in Homebrew/homebrew-core, so brew install apache-spark works out of the box on any macOS with Homebrew — no brew tap step. *Questions for the community* - Any objection to publishing the standalone jar as an additional release artifact under downloads.apache.org/hive/hive-<version>/ ? - For anyone familiar with the existing apache-spark formula in Homebrew/homebrew-core: who owns the update PRs today, and how is that flow handled — is it an individual Spark contributor, a Homebrew maintainer picking up livecheck bumps, or something coordinated through the Spark PMC? I'd like to model our workflow on whatever is working there rather than inventing a new one. Thanks, Illia Barbashov On Wed, Aug 26, 2026 at 4:38 PM Illia Barbashov < [email protected]> wrote: > Yes, since we are using OpenJDK to build the jar artifact, jpackage uses > its JRE for native applications. So it's packaged with The GNU General > Public License (GPL) Version 2. > > Kind regards, > Illia Barbashov > > > On Wed, Aug 26, 2026 at 3:47 PM Stamatis Zampetakis <[email protected]> > wrote: > >> The Hive convenience binaries have LICENSE and NOTICE files at the root >> of the archive to describe the contents. Even though they bundle together >> many jar files it is not sufficient to just have the LICENSE inside the >> jars. I suppose the same requirements apply for any kind of archive that >> appears in the official ASF release repository. I am not a legal expert so >> I would suggest raising a LEGAL Jira ticket to clarify what is required or >> not for the installer. >> >> Distributing a JRE along with Hive binaries requires some extra care >> since different distributions have different licenses. If the JRE is under >> GPL 2.0 with classpath exception then it may be possible to include it in >> the release binaries. The ASF license policy outlines what is allowed or >> not inside binary distributions [1]. >> >> I haven't reviewed the content of the beeline jar since it was added >> recently but I hope that license compliance was checked when the shading >> was introduced. >> >> Best, >> Stamatis >> >> [1] https://www.apache.org/legal/resolved.html >> >> On Wed, Aug 26, 2026 at 4:14 PM Illia Barbashov < >> [email protected]> wrote: >> >>> Hi Stamatis, >>> >>> As I understand it, you mean we must ensure the LICENSE/NOTICE file is >>> shipped correctly for all artifacts, including convenience binaries, and >>> that we comply with the Apache License. Currently, beeline native >>> installers use jpackage to package the beeline-standalone.jar and the JRE >>> to make it work as a native application. I mean that we are merely >>> distributing the fat jar within the native application wrapper. Hence, the >>> apache license should be present in the same way it is for all jars that we >>> distribute. We can also use jpackage to include any files we want >>> inside the native installer. >>> Do you think checking the fat jar's licenses is sufficient for native >>> installers, given that the native app contains only that jar and the JRE >>> needed to run it? >>> >>> Kind Regards, >>> Illia Barbashov >>> >>> On Wed, Aug 26, 2026 at 10:48 AM Stamatis Zampetakis <[email protected]> >>> wrote: >>> >>>> The main release burden I have in mind is related to LICENSE/NOTICE >>>> generation and verification that is quite complex when it comes to >>>> binaries. It's not about signing archives or testing the installers. >>>> >>>> On every release vote the majority of my time is spent on verifying >>>> compliance of LICENSE/NOTICE with ASF guidelines. I am not doing it for >>>> standalone metastore archives and I don't think I will find time to do it >>>> for other binaries. >>>> >>>> Best, >>>> Stamatis >>>> >>>> On Tue, Aug 25, 2026 at 11:14 AM Denys Kuzmenko <[email protected]> >>>> wrote: >>>> >>>>> Hi Team, >>>>> >>>>> +1 for the initiative. >>>>> >>>>> I think adding Beeline native installers as convenient binaries would >>>>> provide a much better experience for users and should not add significant >>>>> overhead to the release process. As Illia pointed out, this would require >>>>> only an additional PGP signing step, with the installers distributed >>>>> alongside the other release artifacts. >>>>> >>>>> We could also add CI coverage to build and validate the installers for >>>>> the supported platforms, reducing the risk of issues during the release >>>>> process. >>>>> >>>>> Overall, the additional release burden seems reasonable compared to >>>>> the convenience and accessibility this would provide to Beeline users. >>>>> >>>>> Best regards, >>>>> Denys >>>>> >>>>
