Skip to content

[MINOR] Build shaded interpreter runtime in zeppelin-interpreter - #5374

Draft
jongyoul wants to merge 1 commit into
apache:masterfrom
jongyoul:codex/unify-interpreter-shading
Draft

[MINOR] Build shaded interpreter runtime in zeppelin-interpreter#5374
jongyoul wants to merge 1 commit into
apache:masterfrom
jongyoul:codex/unify-interpreter-shading

Conversation

@jongyoul

@jongyoul jongyoul commented Aug 3, 2026

Copy link
Copy Markdown
Member

What

  • Build the relocated interpreter runtime JAR from the zeppelin-interpreter package phase while keeping the normal zeppelin-interpreter JAR as the module's only installed/deployed Maven artifact.
  • Remove the separate zeppelin-interpreter-shaded reactor module and its provided dependency from zeppelin-interpreter-parent.
  • Publish the completed runtime JAR to interpreter/, then remove stale versions with a narrowly scoped clean rule.
  • Move dependencies to their actual consumers and remove unused interpreter-runtime dependencies.
  • Update launcher, Docker, downstream shade configuration, contributor guidance, and the 0.12-to-0.13 migration guide.

Why

The separate shaded module creates a two-step rebuild chain that can leave interpreter processes running a stale runtime JAR. Producing both outputs in one module makes a change to zeppelin-interpreter and its runtime JAR part of the same Maven lifecycle without replacing or attaching the public API artifact.

The default runtime JAR is reduced from 9,787,645 bytes to 7,853,798 bytes (1,933,847 bytes / 19.76%) while retaining the existing runtime filename, path, relocations, and optional include-hadoop behavior.

Compatibility

  • Interpreter launchers still consume interpreter/zeppelin-interpreter-shaded-*.jar.
  • org.apache.zeppelin:zeppelin-interpreter-shaded is no longer published. Custom interpreters should use org.apache.zeppelin:zeppelin-interpreter with provided scope and directly declare libraries they use instead of relying on the removed transitive dependencies.
  • The server and integration enforcer rules continue to reject the legacy shaded Maven artifact on their classpaths.

Verification

  • ./mvnw clean test -pl zeppelin-interpreter --am — 126 tests passed.
  • ./mvnw test -pl zeppelin-jupyter-interpreter — 4 kernel tests passed with an isolated compatible Python environment.
  • ./mvnw package -pl zeppelin-server --am -Dtest=ZeppelinConfigurationTest -Dsurefire.failIfNoSpecifiedTests=false — 14 tests passed.
  • ./mvnw package -pl spark/scala-2.12 --am -Pspark-3.5 -Pspark-scala-2.12 -DskipTests.
  • ./mvnw clean package -pl zeppelin-interpreter --am -Pinclude-hadoop -DskipTests.
  • ./mvnw clean package -Pbuild-distr -DskipTests and the same build with -Pinclude-hadoop.
  • ./mvnw clean org.apache.rat:apache-rat-plugin:check -Prat.
  • ./mvnw validate -pl zeppelin-integration --am -Pintegration.
  • Default install verified that only the normal interpreter JAR/POM is installed; the runtime JAR remains distribution-internal.
  • JDBC and Shell Docker flows were built end-to-end with temporary Temurin 11 and git-commit-id-skip substitutions required by the local ARM worktree environment; both final images contained the same runtime JAR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant