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* >> >> 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 >>>>>>> >>>>>>
