[ 
https://issues.apache.org/jira/browse/HIVE-29666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097806#comment-18097806
 ] 

László Bodor edited comment on HIVE-29666 at 7/21/26 9:49 AM:
--------------------------------------------------------------

I would update the description later while this is being worked on, e.g.:
"requires a compatible Java runtime to be installed on the users machine" is 
indeed true, however, it's not the most inconvenient thing, but instead hadoop, 
which is crazy if we want to think of it as simple client app

1. bin/beeline — a thin wrapper that sets HADOOP_CLASSPATH and then execs 
bin/ext/beeline.sh (via the hive executable)
https://github.com/apache/hive/blob/master/bin/beeline
https://github.com/apache/hive/blob/master/bin/hive

2. bin/ext/beeline.sh — defines the beeline() function; sets HADOOP_CLIENT_OPTS 
(JVM opts for the client) and calls:
exec $HADOOP jar ${HIVE_LIB}/hive-beeline-*.jar org.apache.hive.beeline.BeeLine 
"$@"
https://github.com/apache/hive/blob/master/bin/ext/beeline.sh

So Beeline is launched through the hadoop command, not directly via java.

3. hadoop jar … — the Hadoop launcher script assembles the JVM classpath 
(Hadoop common, HDFS, config dirs, native libs) and then runs RunJar, which 
extracts the jar and invokes org.apache.hive.beeline.BeeLine.main().

If HADOOP_HOME is not set, bin/beeline will refuse to start with an error like 
"Cannot find hadoop installation … HADOOP_HOME or HADOOP_PREFIX must be set" 
(this check lives in bin/hive, which beeline sources indirectly through the 
utility scripts under bin/ext/util/).


while shipping a standalone client app, the burden of including dependencies 
(hadoop) is still on hive devs, but in the end, the beeline user should not be 
aware of the hadoop internals (hadoop opts, hadoop home, whatever)
this might be a common shock for a beeline user that:
1. wants to connect to hive
2. downloads beeline jar -> useless alone
3. downloads a full hive distro -> useless without a hadoop environment in this 
sense


was (Author: abstractdog):
I would update the description later while this is being worked on, e.g.:
"requires a compatible Java runtime to be installed on the users machine" is 
indeed true, however, it's not the most inconvenient thing, but instead hadoop, 
which is crazy if we want to think of it as simple client app

1. bin/beeline — a thin wrapper that sets HADOOP_CLASSPATH and then execs 
bin/ext/beeline.sh (via the hive executable)
https://github.com/apache/hive/blob/master/bin/beeline
https://github.com/apache/hive/blob/master/bin/hive

2. bin/ext/beeline.sh — defines the beeline() function; sets HADOOP_CLIENT_OPTS 
(JVM opts for the client) and calls:
exec $HADOOP jar ${HIVE_LIB}/hive-beeline-*.jar org.apache.hive.beeline.BeeLine 
"$@"
https://github.com/apache/hive/blob/master/bin/ext/beeline.sh

So Beeline is launched through the hadoop command, not directly via java.

3. hadoop jar … — the Hadoop launcher script assembles the JVM classpath 
(Hadoop common, HDFS, config dirs, native libs) and then runs RunJar, which 
extracts the jar and invokes org.apache.hive.beeline.BeeLine.main().

If HADOOP_HOME is not set, bin/beeline will refuse to start with an error like 
"Cannot find hadoop installation … HADOOP_HOME or HADOOP_PREFIX must be set" 
(this check lives in bin/hive, which beeline sources indirectly through the 
utility scripts under bin/ext/util/).


while shipping a standalone client app, the burden of including dependencies 
(hadoop) is still on hive devs, but in the end, the beeline user should not be 
aware of the hadoop internals (hadoop opts, hadoop home, whatever)

> Beeline as Standalone executable
> --------------------------------
>
>                 Key: HIVE-29666
>                 URL: https://issues.apache.org/jira/browse/HIVE-29666
>             Project: Hive
>          Issue Type: New Feature
>            Reporter: Attila Turoczy
>            Assignee: Illia Barbashov
>            Priority: Major
>              Labels: Cloud
>
> Provide Beeline as an easy-to-install standalone package for Windows, macOS, 
> and Linux, without requiring users to install or configure a separate Java 
> runtime.
> Beeline is currently distributed as part of the full Hive binary package and 
> requires a compatible Java runtime to be installed on the users machine. This 
> creates significant setup complexity for users who only want to use Beeline 
> as a lightweight SQL command-line client. The current experience is 
> particularly problematic for users who are not developers and may not be 
> familiar with Java installation, environment variables, dependency 
> management, or the full Hive distribution. Trying Beeline should be as simple 
> as downloading or installing a platform-specific package and running the 
> command.
> h2. Goal
> Investigate and implement a standalone Beeline distribution that:
>  * Is available independently from the full Hive binary package.
>  * Does not require a separately installed JRE.
>  * Is simple to install and run for non-developer users.
>  * Supports the main desktop platforms:
>  ** Windows
>  ** macOS on Apple Silicon
>  ** Linux
>  * Keeps the final package as small as reasonably possible.
> h2. Proposed Direction
> One possible approach is to use {{jpackage}} to create a self-contained, 
> platform-specific Beeline application that includes the required Java runtime.
> The investigation should determine whether {{{}jpackage{}}}, or another 
> suitable packaging mechanism, can be used to:
>  * Bundle Beeline with a minimal Java runtime.
>  * Produce native installers or standalone archives.
>  * Create separate artifacts for Windows, macOS, and Linux.
>  * Integrate the packaging process into the existing Hive build and release 
> workflow.
> The final implementation should not be limited to {{jpackage}} if another 
> approach provides a better user experience or produces smaller and 
> easier-to-maintain artifacts.
> h2. Expected User Experience
> A user should be able to:
>  # Download or install the Beeline package for their operating system.
>  # Run the {{beeline}} command without installing Java or the full Hive 
> distribution.
>  # Connect to a supported HiveServer2 endpoint using the existing Beeline 
> command-line parameters.
> h2. Key Design Considerations
> h3. Platform-Specific Builds
> Native packaging may require builds to be executed on the target operating 
> system.
> The build and release process may therefore require:
>  * A Windows build environment.
>  * A macOS build environment, including Apple Silicon support.
>  * A Linux build environment.
>  * Platform-specific signing or notarization, where required.
>  * Changes to the current CI and release infrastructure.
> Cross-compilation support and limitations should be evaluated.
> h3. Package Size
> The resulting package may become large because Beeline currently depends 
> directly or transitively on components such as:
>  * {{hive-exec}}
>  * Hadoop libraries
>  * HDFS libraries
>  * JDBC drivers
>  * Logging frameworks
>  * Authentication and security libraries
> The dependency tree should be reviewed to determine:
>  * Which dependencies are actually required by Beeline.
>  * Whether unnecessary Hive server-side dependencies can be removed.
>  * Whether a dedicated lightweight Beeline module should be introduced.
>  * Whether {{jlink}} can be used to create a reduced Java runtime.
>  * Whether optional integrations can be distributed separately.
> h3. Compatibility
> The standalone package should preserve existing Beeline functionality, 
> including:
>  * JDBC URL-based connections.
>  * Kerberos authentication.
>  * SSL/TLS configuration.
>  * HTTP and binary transport modes.
>  * Authentication mechanisms currently supported by Beeline.
>  * Script execution and command-line options.
>  * Existing configuration-file behavior where applicable.
> h3. Distribution Format
> The investigation should evaluate appropriate formats for each platform, such 
> as:
>  * Windows installer or ZIP archive.
>  * macOS package, application bundle, or archive.
>  * Linux archive and potentially native package formats such as RPM or DEB.
> The initial implementation may use standalone archives if native installers 
> introduce excessive complexity.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to