We just switched to the new Proto library build rules in the [instrumentation-proto](https://github.com/google/instrumentation-proto) repository, by following the instructions at https://bazel.build/blog/index.html#protocol-buffers-in-bazel. Here is the pull request: https://github.com/google/instrumentation-proto/pull/26
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- java
- Domain
- build-system
Research direction
Start by reproducing the supplied bazel build :stats-core_impl command with the listed --javacopt flags and inspect the com_google_protobuf_java target referenced from WORKSPACE. Compare the behavior after the instrumentation-proto build-rule change and determine the precise expected handling of dependency warnings and java_proto_library; the issue is complete only when that behavior is agreed and verified.
Written by the indexing model from the issue text.
Description
We just switched to the new Proto library build rules in the instrumentation-proto repository, by following the instructions at https://bazel.build/blog/index.html#protocol-buffers-in-bazel. Here is the pull request: https://github.com/google/instrumentation-proto/pull/26
Then we updated a git submodule to bring the changes into instrumentation-java, as in this commit: https://github.com/sebright/instrumentation-java/commit/95a6691ea8705f28c9b8a7a7f6ce3fa9d6b1c692
We were building instrumentation-java with --javacopt=-Werror --javacopt=-Xlint:all in CI. After the change, we started getting many errors that seemed to come from the com_google_protobuf_java http_archive target in our WORKSPACE file. Here is part of the list of errors from the failed Travis build:
ERROR: /home/travis/.cache/bazel/_bazel_travis/43f33de0ac8ec257b07378061caba359/external/com_google_protobuf_java/BUILD:553:1: Java compilation in rule '@com_google_protobuf_java//:protobuf_java' failed: Worker process sent response with exit code: 1.
external/com_google_protobuf_java/java/core/src/main/java/com/google/protobuf/AbstractMessage.java:55: warning: [rawtypes] found raw type: AbstractMessageLite
extends AbstractMessageLite
^
missing type arguments for generic class AbstractMessageLite<MessageType,BuilderType>
where MessageType,BuilderType are type-variables:
MessageType extends AbstractMessageLite<MessageType,BuilderType> declared in class AbstractMessageLite
BuilderType extends Builder<MessageType,BuilderType> declared in class AbstractMessageLite
external/com_google_protobuf_java/java/core/src/main/java/com/google/protobuf/AbstractMessage.java:250: warning: [rawtypes] found raw type: List
List list1 = (List) value1;
^
missing type arguments for generic class List<E>
where E is a type-variable:
E extends Object declared in interface List
The full command was:
bazel build :stats-core_impl --javacopt=-Werror --javacopt=-Xlint:all --javacopt=-Xlint:-cast --javacopt=-Xlint:-deprecation --javacopt=-Xlint:-try --verbose_failures
(We were already suppressing some other warnings.)
The full log is at https://travis-ci.org/sebright/instrumentation-java/jobs/212241166 .
Bazel version:
Build label: 0.4.5
Build target: bazel-out/local-fastbuild/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Mar 16 12:19:38 2017 (1489666778)
Build timestamp: 1489666778
Build timestamp as int: 1489666778
I expected bazel to not fail the build in this case, for two reasons:
com_google_protobuf_javais only a dependency of the project. I think there should be a way to only fail if warnings come from the targets in theBUILDfile. (Is there already an option that does that?)java_proto_libraryshouldn't cause errors, because it is a built-in build rule.
/cc @bogdandrutu
Originally posted by @sebright in https://github.com/bazelbuild/bazel/issues/2699 s-out/
antlr3/
contrib/
Documentation/
e2e-tests/
java/
javatests/
lib/
modules/
plugins/
polygerrit-ui/
prolog/
prologtests/
proto/
resources/
tools/
webapp/
polymer-bridges
.bazelignore
.bazelproject
.bazelrc
.bazelversion
.editorconfig
.git-blame-ignore-revs
.gitignore
.gitmodules
.gitreview
.mailmap
.pydevproject
.zuul.yaml
BUILD
COPYING
INSTALL
Jenkinsfile
package.json
README.md
SUBMITTING_PATCHES
version.bzl
web-dev-server.config.mjs
WORKSPACE
yarn.lock
- Dominant language
- TypeScript
- Stars
- 3k
- Forks
- 461
- Avg merge
- 18m
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from devcontainers/cli
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
devcontainers/cli#1203 ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 68/100
devcontainers/cli#1178 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
devcontainers/cli#1308 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
devcontainers/cli#1307 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
devcontainers/cli#1305 ·
All issues in devcontainers/cli
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
dennys-bd/agent-hive#184 ·
-
Add: hunch Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AbdelStark/awesome-typesafe#104 ·
-
ai-observability bug team/ai-observability
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vicharanashala/fln#563 ·