Hi Illia, Publishing an additional jar with some specific classifier does not need a PMC wide decision. The idea clicks for me so if you get a binding +1 review on the PR it should be good to go.
Best, Stamatis On Mon, Sep 21, 2026 at 2:44 PM Illia Barbashov <[email protected]> wrote: > > Hi Stamatis, > > I think maven central can work well for us. In this case we should agree on > releasing one more jar for beeline. I mean the beeline-standalone.jar that is > self sufficient and only requires a JRE that can be installed by brew or > scoop. > > Kind regards, > Illia Barbashov > > On Wed, Sep 16, 2026 at 10:44 AM Stamatis Zampetakis <[email protected]> > wrote: >> >> 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 >>> >>> 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. >>> 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. >>> 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
