Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bazel, module, and JAR upgrades #182

Merged
merged 5 commits into from
Jul 3, 2024
Merged

Bazel, module, and JAR upgrades #182

merged 5 commits into from
Jul 3, 2024

Conversation

mbland
Copy link
Contributor

@mbland mbland commented Jul 2, 2024

Updates as much as possible except rules_jvm_external.

The latest rules_jvm_external v6.1 breaks this project, both under the previous Bazel version (7.0.2) and the new one (7.2.1). I've filed bazel-contrib/rules_jvm_external#1189, which uses this repo and this PR as an example.

See the last section below for details.


Bazel update:

Bazel module updates:

JAR updates:

  • com.google.code.gson:gson:2.11.0
  • com.google.guava:guava:33.2.1-jre
  • commons-cli:commons-cli:1.8.0

Test JAR updates:

  • com.google.googlejavaformat:google-java-format:1.22.0
  • com.google.truth:truth:1.4.3
  • com.google.truth.extensions:truth-java8-extension:1.4.3
  • org.mockito:mockito-core:5.12.0

Added explicit module spec and repinned the maven deps for:

Adding protobuf explicitly resolves these warnings:

DEBUG: .../external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
  The maven repository 'maven' is used in two different bazel modules,
  originally in 'com_engflow_bazel_invocation_analyzer'
  and now in 'protobuf'

DEBUG: .../external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
  The maven repository 'maven' is used in two different bazel modules,
  originally in 'com_engflow_bazel_invocation_analyzer'
  and now in 'protobuf'

DEBUG: .../external/rules_jvm_external~/coursier.bzl:593:18:
    Found duplicate artifact versions
    com.google.code.gson:gson has multiple versions 2.11.0, 2.8.9
    com.google.guava:guava has multiple versions 33.2.1-jre, 31.1-jre
    com.google.truth:truth has multiple versions 1.4.3, 1.1.2
    org.mockito:mockito-core has multiple versions 5.12.0, 4.3.1
Please remove duplicate artifacts from the artifact list so you do not
get unexpected artifact versions

See also:


rules_jvm_external v6.1 somehow creates duplicate jvm_import rules for binary and source jars, instead of using the srcjar attribute:

ERROR: Traceback (most recent call last):
  File ".../external/rules_jvm_external~~maven~maven/BUILD",
    line 34, column 11, in <toplevel>
      jvm_import(

Error in jvm_import: jvm_import rule
  'com_google_auto_value_auto_value_annotations' in package ''
  conflicts with existing jvm_import rule, defined at
  .../external/rules_jvm_external~~maven~maven/BUILD:9:11

The content of rules_jvm_external~~maven~maven/BUILD at lines 9 and 34:

jvm_import(
  name = "com_google_auto_value_auto_value_annotations",
  jars = ["com/google/auto/value/auto-value-annotations/1.10.1/auto-value-annotations-1.10.1.jar"],
jvm_import(
  name = "com_google_auto_value_auto_value_annotations",
  jars = ["com/google/auto/value/auto-value-annotations/1.10.1/auto-value-annotations-1.10.1-sources.jar"],

This pattern repeats for all the JAR targets.

The BUILD contents from v5.3, which builds successfully both before and after applying the PR changes:

jvm_import(
  name = "com_google_auto_value_auto_value_annotations",
  jars = ["com/google/auto/value/auto-value-annotations/1.10.1/auto-value-annotations-1.10.1.jar"],
  srcjar = "com/google/auto/value/auto-value-annotations/1.10.1/auto-value-annotations-1.10.1-sources.jar",

- com.google.code.gson:gson:2.11.0
- com.google.guava:guava:33.2.1-jre
- commons-cli:commons-cli:1.8.0

For Tests
- com.google.googlejavaformat:google-java-format:1.22.0
- com.google.truth:truth:1.4.3
- com.google.truth.extensions:truth-java8-extension:1.4.3
- org.mockito:mockito-core:5.12.0

Signed-off-by: Mike Bland <mbland@engflow.com>
Resolves these warnings:

```txt
DEBUG: .../external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
  The maven repository 'maven' is used in two different bazel modules,
  originally in 'com_engflow_bazel_invocation_analyzer'
  and now in 'protobuf'

DEBUG: .../external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
  The maven repository 'maven' is used in two different bazel modules,
  originally in 'com_engflow_bazel_invocation_analyzer'
  and now in 'protobuf'

DEBUG: .../external/rules_jvm_external~/coursier.bzl:593:18:
    Found duplicate artifact versions
    com.google.code.gson:gson has multiple versions 2.11.0, 2.8.9
    com.google.guava:guava has multiple versions 33.2.1-jre, 31.1-jre
    com.google.truth:truth has multiple versions 1.4.3, 1.1.2
    org.mockito:mockito-core has multiple versions 5.12.0, 4.3.1
Please remove duplicate artifacts from the artifact list so you do not
get unexpected artifact versions
```

See also:

- Duplicate maven repositories when importing bazel_deps that use
  maven.install
  bazel-contrib/rules_jvm_external#916

- Using maven as the repo name causes duplicate warnings when using
  bzlmod
  protocolbuffers/protobuf#16839

- MODULE.bazel doesn't define @maven repository
  protocolbuffers/protobuf#17176

- Stop including extra artifacts on maven.install()
  bazel-contrib/rules_jvm_external#1168

- Use a custom name for the maven repository (maven_protobuf)
  protocolbuffers/protobuf#17190

Signed-off-by: Mike Bland <mbland@engflow.com>
@mbland mbland merged commit ddc353f into main Jul 3, 2024
3 checks passed
@mbland mbland deleted the bazel-and-module-upgrades branch July 3, 2024 14:59
mbland added a commit that referenced this pull request Jul 8, 2024
- https://github.com/bazelbuild/rules_jvm_external/releases/tag/6.2

This new version resolves the issue mentioned in #182:

- bazel-contrib/rules_jvm_external#1189

Fixed by:

- bazel-contrib/rules_jvm_external#1122

Per my comment on that issue, source JARs are no longer fetched without
explicitly setting `fetch_sources = True`. This is why they no longer
appear in `maven_install.json`.

Finally, @shs96c noted to me in private that:

> ...with recent `rules_jvm_external` releases, all you need to update
> is `bazel run @maven//:pin`. There’s no need for the `unpinned_maven`
> repo any more.

I removed the `unpinned_maven` repo and ran `REPIN=1 bazel run
@maven//:pin` to regenerate `maven_install.json`. This also removed the
`unpinned_maven` entries from `MODULE.bazel.lock`.

I'll update this section of my Bzlmod migration blog post after merging
this change:

- https://blog.engflow.com/2024/06/27/migrating-to-bazel-modules-aka-bzlmod---the-easy-parts/#with-rules_jvm_external
mbland added a commit that referenced this pull request Jul 8, 2024
- https://github.com/bazelbuild/rules_jvm_external/releases/tag/6.2

This new version resolves the issue mentioned in #182:

- bazel-contrib/rules_jvm_external#1189

Fixed by:

- bazel-contrib/rules_jvm_external#1122

Per my comment on that issue, source JARs are no longer fetched without
explicitly setting `fetch_sources = True`. This is why they no longer
appear in `maven_install.json`.

Finally, @shs96c noted to me in private that:

> ...with recent `rules_jvm_external` releases, all you need to update
> is `bazel run @maven//:pin`. There’s no need for the `unpinned_maven`
> repo any more.

I removed the `unpinned_maven` repo and ran `REPIN=1 bazel run
@maven//:pin` to regenerate `maven_install.json`. This also removed the
`unpinned_maven` entries from `MODULE.bazel.lock`.

I'll update this section of my Bzlmod migration blog post after merging
this change:

- https://blog.engflow.com/2024/06/27/migrating-to-bazel-modules-aka-bzlmod---the-easy-parts/#with-rules_jvm_external

Signed-off-by: Mike Bland <mbland@engflow.com>
mbland added a commit that referenced this pull request Jul 10, 2024
Details:

- https://github.com/bazelbuild/rules_jvm_external/releases/tag/6.2

This new version resolves the issue mentioned in #182:

- bazel-contrib/rules_jvm_external#1189

Fixed by:

- bazel-contrib/rules_jvm_external#1122

Per my comment on that issue, source JARs are no longer fetched without
explicitly setting `fetch_sources = True`. This is why they no longer
appear in `maven_install.json`.

Finally, @shs96c noted to me in private that:

> ...with recent `rules_jvm_external` releases, all you need to update
is `bazel run @maven//:pin`. There’s no need for the `unpinned_maven`
repo any more.

I removed the `unpinned_maven` repo and ran `REPIN=1 bazel run
@maven//:pin` to regenerate `maven_install.json`. This also removed the
`unpinned_maven` entries from `MODULE.bazel.lock`.

I'll update this section of my Bzlmod migration blog post after merging
this change:

- https://blog.engflow.com/2024/06/27/migrating-to-bazel-modules-aka-bzlmod---the-easy-parts/#with-rules_jvm_external

Signed-off-by: Mike Bland <mbland@engflow.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants