Java class generated from protobuf has compilation errors - protocol-buffers

I'm trying to generated java classes from protobuf.
Below is my protobuf -
syntax = "proto2";
package part2;
option java_package = "part2";
message OnlineStoreUser {
required int32 userid = 1;
required string username = 2;
optional string useremail = 3;
}
I run the command main/exec/protoc --java_out=main/java main/proto/datamodel.proto
The protoc is downloaded from
link https://github.com/protocolbuffers/protobuf/releases/tag/v3.7.1 where osx-x86_64.zip. I tried version 3.8.0 and 3.9.1 as well.
First error is https://gist.github.com/rajcspsg/07c1ddb889410397ba6fc6f26ab2b158#file-gistfile1-txt-L78. The argument to this function UnusedPrivateParameter type is not found.
Second error is https://gist.github.com/rajcspsg/07c1ddb889410397ba6fc6f26ab2b158#file-gistfile1-txt-L890. The is no 2 arg overloaded version of internalBuildGeneratedFileFrom.
What is wrong with my proto file. How can I fix this issue?

Make sure the dependency that you're using in your code is the same as the one that you used as protobuf compiler, for example, here I'm using gradle:
compile group: 'com.google.protobuf', name: 'protobuf-java', version: '3.11.1'
And the for my compiler version is:
✗ protoc --version
libprotoc 3.11.1
Here's my test event:
syntax = "proto2";
option java_package = "com.github.irvifa.protobuf.schema";
message TestEvent {
optional string event_name = 1 [default = "test.event"];
optional string name = 2;
optional string email = 3;
}
And this works.

The errors you mention only happen for me with version 3.9.1. Version 3.7.1 generates a file that doesn't use the UnusedPrivateParameter or the version of internalBuildGeneratedFileFrom with 2 parameters. It rather uses the version with 3 parameters, which does not cause any errors.
Please check that you are using the correct protoc version:
$ main/exec/protoc --version
libprotoc 3.7.1

Related

Unable to build hello_world cc_grpc_library with bazel 6.0.0

I'm trying to build a hello_world cc_grpc_library using bazel 6.0.0 on Ubuntu 22.04, but I'm unable to do so.
Source tree:
WORKSPACE
MODULE.bazel
BUILD
helloworld.proto
.bazelrc
.bazelversion
My WORKSPACE file is empty. WORKSPACE.bzlmod does not exist.
MODULE.bazel contains:
module(name = "helloworld", version = "1.0")
bazel_dep(name = "grpc", version = "1.47.0", repo_name = "com_github_grpc_grpc")
BUILD contains:
load("#rules_proto//proto:defs.bzl", "proto_library")
load("#com_github_grpc_grpc//bazel:grpc_deps.bzl", "grpc_deps")
load("#com_github_grpc_grpc//bazel:grpc_extra_deps.bzl", "grpc_extra_deps")
load("#com_github_grpc_grpc//bazel:cc_grpc_library.bzl", "cc_grpc_library")
grpc_deps()
grpc_extra_deps()
proto_library(
name = "helloworld_proto",
srcs = ["helloworld.proto"],
)
cc_proto_library(
name = "helloworld_cc_proto",
deps = [":helloworld_proto"],
)
cc_grpc_library(
name = "helloworld_cc_grpc",
srcs = [":helloworld_proto"],
grpc_only = True,
deps = [":helloworld_cc_proto"],
)
helloworld.proto is a copy of gRPC's helloworld.proto
When I type bazel build :helloworld_cc_grpc I get the following error and don't know how to solve it:
...external/grpc~1.47.0/bazel/grpc_deps.bzl", line 23, column 11, in grpc_bind_deps
native.bind(
Error: no native function or rule 'bind'
Available attributes: aar_import, action_listener, alias, android_binary, android_device, android_device_script_fixture, android_host_service_fixture, android_instrumentation_test, android_library, android_local_test, android_sdk, android_tools_defaults_jar, apple_cc_toolchain, available_xcodes, cc_binary, cc_host_toolchain_alias, cc_import, cc_libc_top_alias, cc_library, cc_proto_library, cc_shared_library, cc_shared_library_permissions, cc_test, cc_toolchain, cc_toolchain_alias, cc_toolchain_suite, config_feature_flag, config_setting, constraint_setting, constraint_value, environment, existing_rule, existing_rules, exports_files, extra_action, fdo_prefetch_hints, fdo_profile, filegroup, genquery, genrule, glob, j2objc_library, java_binary, java_import, java_library, java_lite_proto_library, java_package_configuration, java_plugin, java_plugins_flag_alias, java_proto_library, java_runtime, java_test, java_toolchain, label_flag, label_setting, objc_import, objc_library, package, package_group, package_name, platform, propeller_optimize, proto_lang_toolchain, proto_library, py_binary, py_library, py_runtime, py_test, repository_name, sh_binary, sh_library, sh_test, subpackages, test_suite, toolchain, toolchain_type, xcode_config, xcode_config_alias, xcode_version
bazel version output:
Bazelisk version: v1.15.0
Build label: 6.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Dec 19 15:52:35 2022 (1671465155)
Build timestamp: 1671465155
Build timestamp as int: 1671465155
I've also found this gRPC github issue but I'm not sure what to do with it.
How to build gRPC's hello world example using bzlmod to manage external dependencies?
I've tried building it with bazel's cc_grpc_library but that wraps actual dependency (gRPC) into yet another layer as it is visible from the comment on the provided link. Either way it wasn't building but I don't recall actual error.
gRPC doesn't yet support Bazel module so it can break but in your case, it looks weird to call grpc_deps() and grpc_extra_deps() functions in BUILD file because those are expected to be called in WORKSPACE file. If it turns out that module doesn't work yet, you may want to use it without module. Please take a look at this example.

undefined: gomock.AssignableToTypeOf

I'm getting this error: undefined: gomock.AssignableToTypeOf
It is occurring while using function gomock.AssignableToTypeOf of package github.com/golang/mock"
This starts occurring when I have Updated versions in the WORKSPACE file of Project, and the error which I'm getting while executing bazel coverage command is undefined: gomock.AssignableToTypeOf
Bazel Version: 4.2.1
Bazel Rules Version: v0.30.0
bazel_gazelle Version: v0.24.0
Go Version: 1.17.6
Docker Rules Version: 0.23.0
It was working fine on the previous versions --
Bazel Version: 3.7.1
Bazel Rules Version: v0.27.0
bazel_gazelle Version: v0.23.0
Go Version: 1.16
Docker Rules Version: 0.14.4
Here's the code snippet of the WORKSPACE file.
# Fetch Golang mock
go_repository(
name = "com_github_golang_mock",
# commit = "aba2ff9a6844d5e3289e8472d3217d5b3090f083",
tag = "v1.6.0",
importpath = "github.com/golang/mock",
)
go_repository(
name = "go_googleapis",
# commit = "aba2ff9a6844d5e3289e8472d3217d5b3090f083",
tag = "v0.69.0",
importpath = "github.com/googleapis/google-api-go-client",
)
go_repository(
name = "org_golang_google_genproto",
tag = "v0.0.0-20220216160803-4663080d8bc8",
importpath = "google.golang.org/genproto",
)
go_repository(
name = "org_golang_x_mod",
importpath = "golang.org/x/mod",
tag = "v0.5.1",
)
go_repository(
name = "org_golang_x_xerrors",
importpath = "golang.org/x/xerrors",
sum = "h1:/atklqdjdhuosWIl6AIbOeHJjicWYPqR9bpxqxYG2pA=",
version = "v0.0.0-20191011141410-1b5146add898",
)
go_repository(
name = "com_github_jmhodges_bazel_gomock",
tag = "v1.3",
importpath = "github.com/jmhodges/bazel_gomock",
)

How correctly run evans (gRPC client)?

I have a city.proto file where I import a well-known third-party package called gogoproto. I created gRPC server and now I want to test it's rpc methods by evans gRPC client.
I used such command but it raise an error:
evans proto/city.proto --host localhost --port 8000
Error:
evans: failed to run REPL mode: failed to instantiate a new spec:
failed to instantiate the spec from proto files: proto: failed to
parse passed proto files: proto/city.proto:7:8: open github.com/gogo/p
rotobuf/gogoproto/gogo.proto: The system cannot find the path
specified.
city.proto:
syntax = "proto3";
package proto;
import "google/protobuf/wrappers.proto";
import "google/protobuf/timestamp.proto";
import "github.com/gogo/protobuf/gogoproto/gogo.proto";
option go_package = "./proto";
message City {
uint64 id = 1 [
json_name = "id",
(gogoproto.jsontag) = "id"
];
google.protobuf.Timestamp foundation_date = 2 [
json_name = "foundation_date",
(gogoproto.jsontag) = "foundation_date",
(gogoproto.nullable) = false,
(gogoproto.stdtime) = true
];
google.protobuf.StringValue name = 3 [
json_name = "name",
(gogoproto.jsontag) = "name",
(gogoproto.wktpointer) = true
];
google.protobuf.StringValue country = 4 [
json_name = "country",
(gogoproto.jsontag) = "country",
(gogoproto.wktpointer) = true
];
}
***
go version:
go version go1.12.9 windows/amd64
protoc version:
libprotoc 3.11.4
evans version:
0.9.0
In all probability, I am not correctly trying to start REPL mode. I assume that the command needs to specify the path to the directory where third-party proto files are located. I am confused. How start evans (gRPC client) correctly?
To run Evans correctly, it's required to specify the correct paths to search for imports by using --path.
It is almost similar to --proto_path in protoc.
For example, we assume that github.com/gogo/protobuf is located in /path/to/github.com/gogo/protobuf:
$ evans --path /path/to --path . proto/city.proto
$ evans --path /path/to --path . --proto proto/city.proto # Better
Note that --path . is also required to search proto/city.proto.
Well-known protos managed by Google such as google/protobuf/wrappers.proto and google/protobuf/timestamp.proto are loaded by default, but in other cases, we have to specify correct paths to use third-party protos.

'No such file or directory' error when using buildGoPackage in nix

I'm trying to build the hasura cli: https://github.com/hasura/graphql-engine/tree/master/cli with the following code (deps derived from dep2nix):
{ buildGoPackage, fetchFromGitHub }:
buildGoPackage rec {
version = "1.0.0-beta.2";
name = "hasura-${version}";
goPackagePath = "github.com/hasura/graphql-engine";
subPackages = [ "cli" ];
src = fetchFromGitHub {
owner = "hasura";
repo = "graphql-engine";
rev = "v${version}";
sha256 = "1b40s41idkp1nyb9ygxgsvrwv8rsll6dnwrifpn25bvnfk8idafr";
};
goDeps = ./deps.nix;
}
but I get the following errors after the post-installation fixup step:
find: '/nix/store/gkck68cm2z9k1qxgmh350pq3kwsbyn8q-hasura-cli-1.0.0-beta.2': No such file or directory.
What am I doing wrong here? For reference, I'm on macOS and using home-manager.
For anyone still wondering:
There are a couple of things to consider:
dep has been deprecated in favor of go modules
This is also reflected in Nix, as buildGoPackage is now legacy and moved to buildGoModule
There is already a hasura-cli package in nixpkgs. You can just use it with nix-shell -p hasura-cli

Vala error "unknown type name" using enum from camel

I am writing this code in Vala, using Camel
using Camel;
[...]
MimeParser par = new MimeParser();
[...]
par.push_state( MimeParserState.MULTIPART, boundary );
I downloaded the camel-1.2.vapi from github vala-girs (this link), put it in a vapi subdirectory and compiled with
valac --vapidir=vapi --includedir=/usr/include/evolution-data-server/camel --pkg camel-1.2 --pkg posix --target-glib=2.32 -o prog prog.vala -X -lcamel-1.2
Compiling I get this error:
error: unknown type name "CamelMimeParserState"
const gchar* camel_mime_parser_state_to_string (CamelMimeParserState self);
Looking the C output code I see that the CamelMimeParserState type is used several times but it is never defined. It should be a simple enum because the camel-1.2.vapi file says:
[CCode (cheader_filename = "camel/camel.h", cprefix = "CAMEL_MIME_PARSER_STATE_", has_type_id = false)]
public enum MimeParserState {
INITIAL,
PRE_FROM,
FROM,
HEADER,
BODY,
MULTIPART,
MESSAGE,
PART,
END,
EOF,
PRE_FROM_END,
FROM_END,
HEADER_END,
BODY_END,
MULTIPART_END,
MESSAGE_END
}
So why doesn't the C output code simply use an enum as the vapi file says (described by cprefix CAMEL_MIME_PARSER_STATE_)?
Is there an error in the .vapi file?
I found the solution. The vapi file is wrong because the cname field is missing. Changing the vapi file adding this cname="camel_mime_parser_state_t":
[CCode (cheader_filename = "camel/camel.h", cname="camel_mime_parser_state_t", cprefix = "CAMEL_MIME_PARSER_STATE_", has_type_id = false)]
public enum MimeParserState {
INITIAL,
[...]
works correctly.

Resources