Bazel Modules (Bzlmod) Migration for Gerrit and Plugins

[David Ostrovsky]

Dear Gerrit Community

Recently, JGit, Gerrit core and its plugin ecosystem have been migrated to Bazel Modules (Bzlmod), and the Bazel version has been upgraded from 7.x to 9.x.

At GerritForge, I gave an internal presentation covering the migration, including the motivation, challenges, and lessons learned for both Gerrit core and plugins.

The session was recorded, and I would like to share it with the community.

In addition, we held follow-up Q&A sessions. Recordings of these sessions are available in the comments section of the presentation video.

Topics covered include:

• Overview of Bazel Modules (Bzlmod)
• Migration strategy for Gerrit and JGit
• Plugin migration approach
• Dependency management and common pitfalls
• Lessons learned and current status

I hope this material is helpful for Gerrit contributors and plugin authors preparing for Bazel 9+.

Presentation slides: https://ostrovsky.org/gerrit/bzlmod/bzlmod_presentation.html

Presentation recording (YouTube): https://www.youtube.com/watch?v=HGtRosf-_K0

Feedback and questions are welcome.

Best regards,
David

[Austin Schuh]

Looks great, this is a very necessary migration.  Thanks for kicking it off.

Consider publishing com_googlesource_gerrit_bazlets to bcr.  I've pushed a couple of other modules before, and the bazel team works hard to make it easy for anyone to contribute modules.  Most/all my contributions merged within a day with very reasonable comments around capturing where things came from, and hints for how the next person can update them.

 

Best regards,
David

Austin 

[sin-ack]

This is awesome, thanks for working on this! I see the changes are still pending, I'm excited to try them out once ready as I'm personally trying to build an out-of-tree plugin myself.

A couple of questions:

- Is maven.install into external_deps considered the final state for now? It kinda feels like an implementation detail. (FWIW I don't think Bazel module extensions are composable, so it's not possible to bundle that call behind a `gerrit_plugin.api()` extension or something AFAICT, which is quite unfortunate.)
- If my plugin depends on an in-tree plugin at the moment (e.g. //plugins/replication:replication-api), what should I do? Are there plans to turn in-tree plugins into Bazel modules of their own (which would make it possible to consume these plugins easily)? I guess once Bzlmod is completely integrated in Gerrit core with the Bazel 9 upgrade, it would also be possible to consume Gerrit itself as a bazel_dep.

[Luca Milanesio]

> On 15 Apr 2026, at 12:19, 'sin-ack' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>
> On Tuesday, April 7, 2026 at 10:40:23 AM UTC+2 David Ostrovsky wrote:
> Dear Gerrit Community
> Recently, JGit, Gerrit core and its plugin ecosystem have been migrated to Bazel Modules (Bzlmod), and the Bazel version has been upgraded from 7.x to 9.x.
> At GerritForge, I gave an internal presentation covering the migration, including the motivation, challenges, and lessons learned for both Gerrit core and plugins.
> The session was recorded, and I would like to share it with the community.
> In addition, we held follow-up Q&A sessions. Recordings of these sessions are available in the comments section of the presentation video.
> Topics covered include:
>
> • Overview of Bazel Modules (Bzlmod)
> • Migration strategy for Gerrit and JGit
> • Plugin migration approach
> • Dependency management and common pitfalls
> • Lessons learned and current status
>
> I hope this material is helpful for Gerrit contributors and plugin authors preparing for Bazel 9+.
> Presentation slides: https://ostrovsky.org/gerrit/bzlmod/bzlmod_presentation.html
> Presentation recording (YouTube): https://www.youtube.com/watch?v=HGtRosf-_K0
> Feedback and questions are welcome.
> This is awesome, thanks for working on this! I see the changes are still pending, I'm excited to try them out once ready as I'm personally trying to build an out-of-tree plugin myself.
> A couple of questions:
> - Is maven.install into external_deps considered the final state for now? It kinda feels like an implementation detail. (FWIW I don't think Bazel module extensions are composable, so it's not possible to bundle that call behind a `gerrit_plugin.api()` extension or something AFAICT, which is quite unfortunate.)
> - If my plugin depends on an in-tree plugin at the moment (e.g. //plugins/replication:replication-api), what should I do?

I believe you should stick to in-tree builds if you are depending on another plugin.

> Are there plans to turn in-tree plugins into Bazel modules of their own (which would make it possible to consume these plugins easily)?

Well, even though it may be possible, I’m not sure how much it would make sense if their audience isn’t very widespread.
Also, it is quite easy to build an in-tree plugin, why would you make all the effort for building a bzlmod if you can just build from source in-tree?

> I guess once Bzlmod is completely integrated in Gerrit core with the Bazel 9 upgrade, it would also be possible to consume Gerrit itself as a bazel_dep.

Well, that should be possible even now and it was also possible before bzlmod thanks to the bazlets.

HTH

Luca.

[sin-ack]

On Wednesday, April 15, 2026 at 2:23:52 PM UTC+2 Luca Milanesio wrote:

> This is awesome, thanks for working on this! I see the changes are still pending, I'm excited to try them out once ready as I'm personally trying to build an out-of-tree plugin myself.
> A couple of questions:
> - Is maven.install into external_deps considered the final state for now? It kinda feels like an implementation detail. (FWIW I don't think Bazel module extensions are composable, so it's not possible to bundle that call behind a `gerrit_plugin.api()` extension or something AFAICT, which is quite unfortunate.)
> - If my plugin depends on an in-tree plugin at the moment (e.g. //plugins/replication:replication-api), what should I do?

I believe you should stick to in-tree builds if you are depending on another plugin. 

Understood. 

 

> Are there plans to turn in-tree plugins into Bazel modules of their own (which would make it possible to consume these plugins easily)?

Well, even though it may be possible, I’m not sure how much it would make sense if their audience isn’t very widespread.
Also, it is quite easy to build an in-tree plugin, why would you make all the effort for building a bzlmod if you can just build from source in-tree? 

It's kind of a weird setup (IMHO) to have third-party plugins as subdirectories within the main Gerrit tree, and it prevents plugins from having their own dependencies that shouldn't necessarily be present in Gerrit's own MODULE.bazel. The Javamelody plugin seems to be a nice example.

 

> I guess once Bzlmod is completely integrated in Gerrit core with the Bazel 9 upgrade, it would also be possible to consume Gerrit itself as a bazel_dep.

Well, that should be possible even now and it was also possible before bzlmod thanks to the bazlets.  

When I tried it, some things were broken with Bazlets AFAICT, such as the gerrit_js_bundle stuff. There's also some things like the Eslint/TypeScript setup that's currently inside the main Gerrit repository only.

HTH

Luca.

Kind regards,
sin-ack 

[Nasser Grainawi]

On Wed, Apr 15, 2026 at 7:26 AM 'sin-ack' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

On Wednesday, April 15, 2026 at 2:23:52 PM UTC+2 Luca Milanesio wrote:

> This is awesome, thanks for working on this! I see the changes are still pending, I'm excited to try them out once ready as I'm personally trying to build an out-of-tree plugin myself.
> A couple of questions:
> - Is maven.install into external_deps considered the final state for now? It kinda feels like an implementation detail. (FWIW I don't think Bazel module extensions are composable, so it's not possible to bundle that call behind a `gerrit_plugin.api()` extension or something AFAICT, which is quite unfortunate.)
> - If my plugin depends on an in-tree plugin at the moment (e.g. //plugins/replication:replication-api), what should I do?

I believe you should stick to in-tree builds if you are depending on another plugin. 

Understood. 

This is probably the simplest to do for now, but it would be nice to be more flexible. Especially for plugins like the its-* ones where they depend on 'its-base'.

 

 

> Are there plans to turn in-tree plugins into Bazel modules of their own (which would make it possible to consume these plugins easily)?

Well, even though it may be possible, I’m not sure how much it would make sense if their audience isn’t very widespread.
Also, it is quite easy to build an in-tree plugin, why would you make all the effort for building a bzlmod if you can just build from source in-tree? 

It's kind of a weird setup (IMHO) to have third-party plugins as subdirectories within the main Gerrit tree, and it prevents plugins from having their own dependencies that shouldn't necessarily be present in Gerrit's own MODULE.bazel. The Javamelody plugin seems to be a nice example.

Agreed. I'm also hoping we can do more to make more plugins simple to build standalone.

 

 

> I guess once Bzlmod is completely integrated in Gerrit core with the Bazel 9 upgrade, it would also be possible to consume Gerrit itself as a bazel_dep.

Well, that should be possible even now and it was also possible before bzlmod thanks to the bazlets.  

When I tried it, some things were broken with Bazlets AFAICT, such as the gerrit_js_bundle stuff. There's also some things like the Eslint/TypeScript setup that's currently inside the main Gerrit repository only.

Depending on what issue you had with gerrit_js_bundle, it might be fixed now. And yes, the typescript support has been missing from bazlets and I'm hoping the bzlmod refactor can be used as a step towards fixing that since Gerrit core now leverages bazlets. Thomas currently has some changes up for review in bazlets that might be improving that (I haven't reviewed them closely): 536282: Move UI macros for plugins to bazlets | https://gerrit-review.googlesource.com/c/bazlets/+/536282

Nasser

 

HTH

Luca.

Kind regards,
sin-ack 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/fdcf11cc-1eda-4fce-8d03-840b0185fc94n%40googlegroups.com.