You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Release the java runfiles library as a maven coordinate #360
When working on a project that doesn't build with bazel but needs to use the runfiles library (for example, when porting a project from gradle to bazel) there's no easy way to access the java runfiles library. The Python world exports theirs as a wheel.
It would be helpful to expose the java runfiles library as a maven coordinate.
Bazel projects can either not use the coordinate or use a maven.override to point to the Bazel-provided version.
If it's just for migration purposes, checking in the runfiles library into the project and using it as a local repository seems simple enough.
Unless we can re-use existing accounts/infrastructure/tooling (cc @cushon i think we publish turbine as a maven artifact?) , I'm (personally) not inclined towards adding/maintaining this.
For turbine I'm using maven and the sonatype plugin to release the artifacts to maven central, and there's some github actions automation (https://github.com/google/turbine/blob/main/.github/workflows/release.yml). Some of that predates java_export, I guess that's probably the approach we'd want for this? Anyway I don't think we can trivially re-use what we're doing for turbine and I don't have bandwidth to set up a maven release for this right now.
We also have a usecase for this. We have Maven and Bazel builds working in parallel. Bazel is the source of truth and we have a tool that keeps the Maven build in sync.
Currently we have a step before we run Maven that copies the jars for the runfiles library out of Bazel and installs them to ~/.m2 where Maven can see them, but if they are available from a Maven repo somewhere instead then we don't need that step.
More generally, any time you need something that doesn't understand Bazel to understand your code, especially IDEs/LSPs and test runners, the runfiles library can get in the way, so I think publishing them to each language's package manager is the right approach.
Reacted by Fabian Meumertzheim and Simon Mavi Stewart
@cushonjava_export is designed for exactly this kind of thing. I can prep a PR for the bazel repo to add the target, though as you say that's the simplest bit of the entire process.
As an alternative, we could lift the runfiles helper library into an existing bazel ruleset (or even a new project in bazel-contrib). I'm sure that there are people in the community who can handle releasing things to Maven Central.
Activity
hvadehra commentedon Jun 29, 2026
If it's just for migration purposes, checking in the runfiles library into the project and using it as a local repository seems simple enough.
Unless we can re-use existing accounts/infrastructure/tooling (cc @cushon i think we publish turbine as a maven artifact?) , I'm (personally) not inclined towards adding/maintaining this.
cushon commentedon Jun 29, 2026
For turbine I'm using maven and the sonatype plugin to release the artifacts to maven central, and there's some github actions automation (https://github.com/google/turbine/blob/main/.github/workflows/release.yml). Some of that predates
java_export, I guess that's probably the approach we'd want for this? Anyway I don't think we can trivially re-use what we're doing for turbine and I don't have bandwidth to set up a maven release for this right now.docs: establish project versioning and compatibility policy (#1)
jesses-canva commentedon Jun 30, 2026
We also have a usecase for this. We have Maven and Bazel builds working in parallel. Bazel is the source of truth and we have a tool that keeps the Maven build in sync.
Currently we have a step before we run Maven that copies the jars for the runfiles library out of Bazel and installs them to
~/.m2where Maven can see them, but if they are available from a Maven repo somewhere instead then we don't need that step.More generally, any time you need something that doesn't understand Bazel to understand your code, especially IDEs/LSPs and test runners, the runfiles library can get in the way, so I think publishing them to each language's package manager is the right approach.
shs96c commentedon Aug 11, 2026
@cushon
java_exportis designed for exactly this kind of thing. I can prep a PR for the bazel repo to add the target, though as you say that's the simplest bit of the entire process.As an alternative, we could lift the runfiles helper library into an existing bazel ruleset (or even a new project in
bazel-contrib). I'm sure that there are people in the community who can handle releasing things to Maven Central.