Fix things after bzlmod migration

[agluszak]

Second attempt at bzlmod migration. This time there's almost no naming changes and I verified that it works in IntelliJ 2023.3 on Linux.

Fixes #5432.

TODO:

• Fix test com.google.idea.blaze.base.qsync.DependencyTrackerImplTest.getPendingExternalDeps_followJavaDeps_allBuilt(DependencyTrackerImplTest.java:201)
• Figure out how to regenerate the module lockfile for all systems/configurations at once (cc @tpasternak)
• [] Test on non-Linux OSes

[agluszak]

bazel-contrib/rules_jvm_external#1016 the problem with grpc-java dependency names seems to have been fixed now, so I can revert that part if you consider it problematic @mai93

[mai93]

Yes, I think it will be better if we removed the extra files: non_module_deps.bzl, tools/BUILD and tools/java_grpc_library.bzl.

For getPendingExternalDeps_followJavaDeps_allBuilt(DependencyTrackerImplTest.java:201), we need to change the dependency label added here with the full label with the dependency repo name including the ~ to keep it testing the same thing and the expected result should be empty.

[agluszak]

bazelbuild/rules_jvm_external#1016 the problem with grpc-java dependency names seems to have been fixed now, so I can revert that part if you consider it problematic @mai93

Unfortunately as I mentioned in Slack it turned out that grpc-java dependency names are still incompatible with names used in this repository. So we have to either

1. change the names used in this repo (so we'd be back to 100 BUILD file changes)
2. use this solution which removes the source dependency on grpc-java
3. wait until grpc-java migrates to bzlmod (which can take a lot of time)

[mai93]

@Wyverald we are trying to migrate the plugin to use bzlmod and we have a problem with the lock file. the plugin has a dependency on rules_go which adds an entry in the lock file that is specific to the architecture on which it is created, this causes a problem when the plugin is built on a different OS/architecture. Is there a way around this? @tpasternak for more details

[Wyverald]

this causes a problem when the plugin is built on a different OS/architecture

What is the problem? If you use the latest rules_go, then the lockfile would contain different sections for rules_go depending on which platform you're building on. You'd need to update the lockfile from each of those different platforms, but ultimately they shouldn't step on each other's toes.

cc @SalmaSamy

[SalmaSamy]

@mai93 As @Wyverald mentioned the lockfile should handle this you just have to make sure:

1. The rules_go version you're using contains this change
2. The bazel version you're using contains this change

Basically, using the latest in both should result in a lockfile with sections for each platform like the example here

[mai93]

@tpasternak FYI, the response from bazel team about bzlmod lock file question

[tpasternak]

Some loose thoughts:

1. I'm getting this warning when trying to build the project:

DEBUG: /home/t/.cache/bazel/_bazel_t/9f891cf4952c58dbb7dca5b940b19431/external/rules_jvm_external~override/private/extensions/maven.bzl:139:14: The maven repository 'maven' is used in two different bazel modules, originally in '' and now in 'protobuf'

2. I'm still getting some modifications to MODULE.bazel after build, like this one:

     "@@bazel_tools//tools/cpp:cc_configure.bzl%cc_configure_extension": {
       "general": {
-        "bzlTransitiveDigest": "O9sf6ilKWU9Veed02jG9o2HM/xgV/UAyciuFBuxrFRY=",
+        "bzlTransitiveDigest": "mcsWHq3xORJexV5/4eCvNOLxFOQKV6eli3fkr+tEaqE=",
         "accumulatedFileDigests": {},
         "envVariables": {},
         "generatedRepoSpecs": {
@@ -1894,7 +1903,14 @@
               "name": "bazel_tools~cc_configure_extension~local_config_cc_toolchains"
             }
           }
-        }
+        },
+        "recordedRepoMappingEntries": [
+          [
+            "bazel_tools",
+            "bazel_tools",
+            "bazel_tools"
+          ]
+        ]
       }
     },

3. I'm not sure what was the conclusion from the last meeting/chats, but we've been talking about keeping rules_go in as a non-bzlmod dep

4. Same for grpc - this might be quite hard to maintain, so personally I would prefer to keep in the WORKSPACE def, too, but it's not a strong opinion, current is also ok.

[mai93]

I think the test for version 4.2.4 is missing: https://buildkite.com/bazel/intellij-plugin-aspect/builds/21280#018dd20e-4bca-481d-8d9b-060f884523f5.

We actually need to test with a version before 6 and a version after it because based on that we change the label of the aspect repo in the sync invocation.

[mai93]

I addressed the comments I had and manually tested it. I will merge it tomorrow if no one has a problem.

[agluszak]

Thanks @mai93! Sorry for not handling it, I don't work on Mondays and Tuesdays