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 is somewhat of a rough cut, since it doesn't split apart the lite and full targets, or unit tests. However, it does split sources under src/google/protobuf into a separate package, which is a fairly impactful change.
This avoids conflicting names in a couple of cases.
1. Within google, we want to sync files but not name them BUILD (since the structure doesn't match).
2. On case-insensitive filesystems, `build` may be used for a build directory. Naming `BUILD.bazel` avoids potentioal conflicts.
This change adds `rules_pkg`-based targets that will produce source distribution archives, similar to `make dist`.
These rules produce nearly the same outputs as `make dist`. However, there are some differences and caveats:
1. The outputs do not contain vendored googletest sources.
2. You have to run `autogen.sh` before `blaze build pkg:all`. This produces several autotools-related files directly into the source tree.
3. The output .zip files do not have a directory prefix like `protobuf-3.20.1-rc-1` (this will be addressed after [Substitute package variables in `pkg_zip#package_dir`. bazelbuild/rules_pkg#577](https://github.com/bazelbuild/rules_pkg/pull/577); the tar files do have this prefix, though.)
4. One file is missing from the archives, which is produced during the `make` build: benchmarks/gogo/cpp_no_group/cpp_benchmark.cc
5. In several places, I have explicitly excluded some files that are not in the autotools distribution outputs. I think most of those files should probably be included, but for now, I'm aiming for parity with `make dist`. These are marked with comments, so it should be easy to clean them up later.
This commit removes the use of bind() since that function goes against
Bazel best practices:
https://docs.bazel.build/versions/main/external.html#repository-rules-1
The bind() function basically maps a dependency into //external, but
there is no good reason to do this. By mapping dependencies into
//external and relying on this in our own BUILD files, we're forcing
projects that depend on us to do the same. The one bind() call that I
did leave in place was //:python_headers. This one seems to be doing
something complicated I don't fully understand, and I don't want to risk
breaking it.
This change also moves our list of required Maven artifacts into a
constant in protobuf_deps.bzl. This way, projects that depend on us can
refer to this list when they invoke maven_install() and automatically
pull in all the necesary dependencies.
This fixes#9132.
* properly ignore WKTs in lang_proto_toolchain for java
We already pre-compile the well known types into the runtimes so they shouldn't be re-compiled. #8925
* remove accidental proto addition.
* Protobuf Java/Core Tests running w/ Bazel.
Also integrates rules_jvm_external and migrates existing maven deps
in place.
* Add test_suite target that maps to rule name.
* Lite tests passing in Bazel
* util tests passing with Bazel.
* Add conformance and build testing to //java:core
* Cleanup bzl style and lock down access to failure lists.
* Adding Java Lite conformance tests.
* rm newline
* parameterize conformance_test
This makes usage of failure lists more explicit.
* restrict visibility more for newly added libs and fix formatting.
* fix formatting and visibility.
* move testing.bzl to an internal package.
* fix file formatting.
* moving conformance_test to internal.bzl
* [bazel] Move Java runtime/toolchains into //java
This change moves `java_library` targets from the top-level BUILD file
into `//java/{core,lite,util}` and declares `alias` targets to point to
their new locations (hence, this is not a breaking change).
This will allow users that don't use Java to stop depending on
`@rules_java` (e.g. as requested in
https://github.com/bazelbuild/rules_scala/pull/989#issuecomment-583405161).
Note that there is no intention to deprecate + remove the top-level
targets in the foreseeable future.
* Add BUILD files in //java to java_EXTRA_DIST