* master: (39 commits)
  Fix resolution of Android/AAR artifacts with Gradle resolver (bazel-contrib#1395)
  fail_if_repin_required is now True by default and minor improvement to failure message (bazel-contrib#1397)
  Housekeeping before we release 6.8 (bazel-contrib#1384)
  Add dll, dylib and so types to maven package mappings (bazel-contrib#1392)
  [bzlmod] Allow suppressing warning about multiple contributing modules. (bazel-contrib#1393)
  Use the artifact default values when adding them to a struct and add tests for coursier artifacts that have empty versions provided by BOMs and don't inlcude them in outdated (bazel-contrib#1390)
  Allow package exclusions and inclusions in javadocs (bazel-contrib#1293)
  Document well-known issues with `bzlmod` (bazel-contrib#1388)
  Begin documenting the gradle resolver (bazel-contrib#1389)
  Run gradle regression tests in CI (bazel-contrib#1385)
  Modify maven_export to allow exporting zip archives (bazel-contrib#1368)
  Allow root module's override tags to take precedence over the overridees from transitive deps. (bazel-contrib#1381)
  Ensure root module artifacts and boms take precedence with warnings (bazel-contrib#1373)
  Update maven-metadata.xml when publishing locally (bazel-contrib#1369)
  Add support for gradle resolver (bazel-contrib#1357)
  Prepare for 6.8 release (bazel-contrib#1380)
  Remove the Windows `kt_jvm_export` example (bazel-contrib#1383)
  Avoid spurious warnings about poorly formatted artifact coordinates (bazel-contrib#1374)
  Flip `fail_if_repin_required` to `True` by default (bazel-contrib#1371)
  Allow the same coordinate to be overridden in different repos (bazel-contrib#1378)
  ...

Fixes #21177

This PR essentially reverts #18641, which claimed

> Since protobuf is not contributing to user's JARs

This is not true since targets like `@com_google_protobuf//:protobuf_java` are meant to be consumed by other projects, therefore protobuf should not use a private maven install namespace. Otherwise, it leads to duplicated maven jars and classpath conflicts. See #21177 and bazel-contrib/rules_jvm_external#916 (comment)

The original warning message caused by multiple modules contributing to `maven` can be suppressed with bazel-contrib/rules_jvm_external#1393, which will be available in rules_jvm_external 6.8.

The PR use a repo mapping trick of `use_repo` to keep BUILD files intact, underlying both `protobuf_maven` and `protobuf_maven_dev` points to the universal `maven` install, while targets in `protobuf_maven_dev` are only available while protobuf is the root module and won't propagate to dependents.

PiperOrigin-RevId: 781031722

Fixes #21177

This PR essentially reverts #18641, which claimed

> Since protobuf is not contributing to user's JARs

This is not true since targets like `@com_google_protobuf//:protobuf_java` are meant to be consumed by other projects, therefore protobuf should not use a private maven install namespace. Otherwise, it leads to duplicated maven jars and classpath conflicts. See #21177 and bazel-contrib/rules_jvm_external#916 (comment)

The original warning message caused by multiple modules contributing to `maven` can be suppressed with bazel-contrib/rules_jvm_external#1393, which will be available in rules_jvm_external 6.8.

The PR use a repo mapping trick of `use_repo` to keep BUILD files intact, underlying both `protobuf_maven` and `protobuf_maven_dev` points to the universal `maven` install, while targets in `protobuf_maven_dev` are only available while protobuf is the root module and won't propagate to dependents.

PiperOrigin-RevId: 781031722

Fixes #21177

This PR essentially reverts #18641, which claimed

> Since protobuf is not contributing to user's JARs

This is not true since targets like `@com_google_protobuf//:protobuf_java` are meant to be consumed by other projects, therefore protobuf should not use a private maven install namespace. Otherwise, it leads to duplicated maven jars and classpath conflicts. See #21177 and bazel-contrib/rules_jvm_external#916 (comment)

The original warning message caused by multiple modules contributing to `maven` can be suppressed with bazel-contrib/rules_jvm_external#1393, which will be available in rules_jvm_external 6.8.

The PR use a repo mapping trick of `use_repo` to keep BUILD files intact, underlying both `protobuf_maven` and `protobuf_maven_dev` points to the universal `maven` install, while targets in `protobuf_maven_dev` are only available while protobuf is the root module and won't propagate to dependents.

PiperOrigin-RevId: 781031722

Fixes #21177

This PR essentially reverts #18641, which claimed

> Since protobuf is not contributing to user's JARs

This is not true since targets like `@com_google_protobuf//:protobuf_java` are meant to be consumed by other projects, therefore protobuf should not use a private maven install namespace. Otherwise, it leads to duplicated maven jars and classpath conflicts. See #21177 and bazel-contrib/rules_jvm_external#916 (comment)

The original warning message caused by multiple modules contributing to `maven` can be suppressed with bazel-contrib/rules_jvm_external#1393, which will be available in rules_jvm_external 6.8.

Closes #22544

PiperOrigin-RevId: 782032198