@@ -45,15 +45,6 @@ users pick up the correct order of dependencies for `rules_scala`. If you want
45
45
to override any of the following dependency versions, make sure to ` load() ` them
46
46
before calling ` rules_scala_dependencies() ` .
47
47
48
- As of version 7.0.0, __ ` rules_scala ` no longer requires the
49
- ` io_bazel_rules_scala ` repository name__ unless your ` BUILD ` files or those of
50
- your dependencies require it (bazelbuild/rules_scala #1696 ).
51
-
52
- Note that __ ` rules_scala ` 7 introduces a new ` scala_toolchains() ` API that is
53
- very different from ` rules_scala ` 6__ . For details on what's changed, see the
54
- [ New ` scala_toolchains() ` API for ` WORKSPACE ` ] ( #new-toolchains-api ) section
55
- below.
56
-
57
48
``` py
58
49
# WORKSPACE
59
50
load(" @bazel_tools//tools/build_defs/repo:http.bzl" , " http_archive" )
@@ -150,6 +141,20 @@ scala_toolchains(
150
141
scala_register_toolchains()
151
142
```
152
143
144
+ ### Important changes in ` rules_scala ` v7.0.0 configuration
145
+
146
+ The above configuration snippet reflects important changes since ` rules_scala `
147
+ v6.x:
148
+
149
+ - __ ` rules_scala ` no longer requires the ` io_bazel_rules_scala ` repository
150
+ name__ unless your ` BUILD ` files or those of your dependencies require it
151
+ (bazelbuild/rules_scala #1696 ).
152
+
153
+ - __ ` rules_scala ` v7.0.0 introduces a new ` scala_toolchains() ` API that is
154
+ very different from ` rules_scala ` 6__ . For details on what's changed, see
155
+ the [ New 'scala_toolchains()' API for 'WORKSPACE'] ( #new-toolchains-api )
156
+ section below.
157
+
153
158
### Loading the ` scala_* ` rules
154
159
155
160
Add the following to your ` BUILD ` files to make the ` scala_* ` rules available:
@@ -442,7 +447,7 @@ scala_toolchains(
442
447
scala_register_toolchains()
443
448
```
444
449
445
- See the [ ` scala_toolchains() ` docstring ] ( ./scala/toolchains.bzl ) for the
450
+ See the [ ` scala_toolchains() ` ] ( ./scala/toolchains.bzl ) docstring for the
446
451
parameter list, which is almost in complete correspondence with parameters from
447
452
the previous macros. The ` WORKSPACE ` files in this repository also provide many
448
453
examples.
@@ -526,8 +531,8 @@ The `MODULE.bazel` files in this repository will also provide many examples
526
531
527
532
### Embedded resource paths no longer begin with ` external/<repo_name> `
528
533
529
- [ Any program compiled with an external repo asset in its ` resources ` attribute
530
- will need to strip the ` external/ ` and repo name components from its
534
+ [ Any program compiled with an external repo asset in its ' resources' attribute
535
+ will need to strip the ' external/' and repo name components from its
531
536
path] [ ext-path ] . For example, the path for `resources =
532
537
[ "@some_external_repo//: resource .txt"] ` would change thus:
533
538
@@ -646,15 +651,15 @@ future compatibility.
646
651
### <a id =" 6.5.0 " ></a >Limited Bazel 6.5.0 compatibility
647
652
648
653
` rules_scala ` 8.0.0 will not support Bzlmod with Bazel 6.5.0 because
649
- [ Bazel 6.5.0 doesn't support ` use_repo_rule ` ] (
654
+ [ Bazel 6.5.0 doesn't support ' use_repo_rule' ] (
650
655
https://bazel.build/versions/6.5.0/rules/lib/globals ), which
651
- [ ` rules_jvm_external ` >= 6.3 requires] (
656
+ [ ' rules_jvm_external' >= 6.3 requires] (
652
657
https://github.com/bazelbuild/rules_scala/issues/1482#issuecomment-2515496234 ).
653
658
654
659
` WORKSPACE ` builds will continue to work with Bazel 6.5.0, but not out of the
655
- box. Per #1647 , using Bazel 6.5.0 with ` rules_scala ` 8.x will require adding the
656
- following flags to ` .bazelrc ` , required by the newer ` abseil-cpp ` version used
657
- by ` protobuf ` :
660
+ box. Per bazelbuild/rules_scala #1647 , using Bazel 6.5.0 with ` rules_scala ` 8.x
661
+ will require adding the following flags to ` .bazelrc ` , required by the newer
662
+ ` abseil-cpp ` version used by ` protobuf ` :
658
663
659
664
``` txt
660
665
common --enable_platform_specific_config
@@ -677,8 +682,8 @@ improves performance.
677
682
[ ` compatibility_level ` ] ( https://bazel.build/external/module#compatibility_level )
678
683
values for their [ ` module() ` ] ( https://bazel.build/rules/lib/globals/module )
679
684
directives. This is due to the gap in supported ` protobuf ` versions documented
680
- in #1647 (between v25.5 and v28) and dropping support for Bazel 6.5.0 Bzlmod
681
- builds.
685
+ in bazelbuild/rules_scala #1647 (between v25.5 and v28) and dropping support for
686
+ Bazel 6.5.0 Bzlmod builds.
682
687
683
688
This will ensure any users attempting to mismatch ` protobuf ` and ` rules_scala `
684
689
versions will break during module resolution, rather than during a later
@@ -693,8 +698,8 @@ versioning](https://semver.org/)), and clearly document the reason for the level
693
698
bump. If a version bump may break builds for any known reason, we will explain
694
699
why up front instead of waiting for users to be surprised.
695
700
696
- [ A comment from #1647 illustrates how ` rules_erlang ` fails due to
697
- ` compatibility_level ` conflicts] [ erlang ] . The [ ` rules_erlang ` 3.0.0 release
701
+ [ A comment from #1647 illustrates how ' rules_erlang' fails due to
702
+ ' compatibility_level' conflicts] [ erlang ] . The [ ' rules_erlang' 3.0.0 release
698
703
notes] ( https://github.com/rabbitmq/rules_erlang/releases/tag/3.0.0 ) describe the
699
704
breaking changes. This seems like a reasonable model to follow.
700
705
0 commit comments