The default name for the rules_jvm_external.maven rule is "maven". When not set, it defaults to "maven". For root modules also using rules_jvm_external, the name clash causes a warning:
```
DEBUG: $TMP/external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
The maven repository 'maven' is used in two different bazel modules,
originally in '<my_workspace>' and now in 'protobuf'
```
Summarizing @shs96c in [1]:
> The common maven repo name allows rulesets to contribute to the user's JARs.
> However, this implies that maven is for the end user, not for transitive
> dependencies. If a ruleset needs private dependencies, it should use a custom
> namespace rather than the maven namespace.
Since protobuf is not contributing to user's JARs, we'll use a custom namespace. There's precedent for using a custom namespace for library modules:
- rules_jvm_external uses `rules_jvm_external_deps` instead of `maven`.
- rules_kotlin uses `kotlin_rules_maven` instead of `maven`.
[1]: https://github.com/bazel-contrib/rules_jvm_external/issues/916#issuecomment-1645527584Fixes#16839.
Closes#18641
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18641 from jschaf:joe/protobuf-maven bd2c62f311
PiperOrigin-RevId: 684625084
We mostly use generated pom files in our release currently, so we can delete all the files that aren't used and the tools to update them.
Note, java/bom/pom.xml java/pom.xml and java/protoc/pom.xml are all still used at release and java/kotlin/pom.xml is used for documentation so all of those need to stay for now.
PiperOrigin-RevId: 659664012
The only public target here is the edition defaults helper macro, which can be used by external runtimes and plugins. None of this code is C++-specific though, and should be organized higher up. Appropriate aliases are also placed at the top level for public targets
PiperOrigin-RevId: 625392504
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
This also fixes maven to package this correctly as google/protobuf/java_features.proto (same dir as WKT/descriptor.proto) instead of com/google/protobuf/java_features.proto.
Fixes https://github.com/protocolbuffers/protobuf/issues/16155
PiperOrigin-RevId: 619015714
GeneratedMessage, not GeneratedMessageV3.
Please rerun protoc on your .proto files to regenerate the binding code.
https://protobuf.dev/news/2023-12-05/https://protobuf.dev/support/cross-version-runtime-guarantee/
To fix source compatibility with surrounding code make these replacements:
GeneratedMessageV3 --> GeneratedMessage
SingleFieldBuilderV3 --> SingleFieldBuilder
RepeatedFieldBuilderV3 --> RepeatedFieldBuilder
PiperOrigin-RevId: 597642289
* Fix mutability bug in Java proto lite: sub-messages inside of oneofs were not
being set as immutable. This would allow code to get a builder for a
sub-message and modify the original (supposedly immutable) copy.
PiperOrigin-RevId: 511598810
* Add casts to make protobuf compatible with Java 1.8 runtime.
Fix for: https://github.com/protocolbuffers/protobuf/issues/11393
PiperOrigin-RevId: 511807920
---------
Co-authored-by: Protobuf Team Bot <protobuf-github-bot@google.com>
Joe Schafer
Protobuf Team Bot
Deanna Garcia
zhangskz
Mike Kruskal
Mike Kruskal
Sandy Zhang
Sam Gammon
aiuto
Dennis Shao
Jie Luo
Protobuf Team Bot
Joshua Haberman
ericsalo
deannagarcia
Jerry Berg