Thanks for driving this Illia! Do we need to publish the jar in downloads.apache.org? Can't we publish it in maven central during the regular install deploy phase?
Regarding the apache-spark workflow I would suggest reaching out to [email protected] list in order to gather the required information. Best, Stamatis On Tue, Sep 15, 2026 at 3:28 PM Illia Barbashov < [email protected]> wrote: > 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 >>>>>> >>>>>
