Skip to content

Release the java runfiles library as a maven coordinate #360

Description

@shs96c

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.

Activity

  1. hvadehra commented on Jun 29, 2026

    @hvadehra
    Member

    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.

  2. added
    P4This is either out of scope or we don't have bandwidth to review a PR. (No assignee)
    on Jun 29, 2026
  3. added theissue type on Jun 29, 2026
  4. cushon commented on Jun 29, 2026

    @cushon
    Collaborator

    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.

  5. jesses-canva commented on Jun 30, 2026

    @jesses-canva

    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.

  6. shs96c commented on Aug 11, 2026

    @shs96c
    Author

    @cushon java_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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P4This is either out of scope or we don't have bandwidth to review a PR. (No assignee)

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions