Eclipse build path about rules_protobuf HOT 12 CLOSED

Hi @kd8azz. I'm not an eclipse user (basic emacs), but if you can point me in the right direction of what kind of file eclipse is looking for, we can probably figure it out. I'm assuming you want eclipse to auto-complete, right?

Also, are you using https://github.com/bazelbuild/e4b by any chance?

from rules_protobuf.

Best I can tell, your output gives me a .jar file containing sources, whereas eclipse wants a .jar file containing class files. I figure I could probably do some manual steps, myself, to make it work, but I'm trying to avoid that.

Thanks for the link; I'll take a look at e4b.

from rules_protobuf.

I would like autocomplete, but at this point I'd settle for eclipse being able to build the project. (Eclipse has its own internal compiler)

from rules_protobuf.

Are you able to get eclipse to build a bazel-based project without protobufs?

from rules_protobuf.

Yeah, I've manually curated a classpath, linking in the jars bazel downloads for me. (My WORKSPACE has a dozen or so maven dependencies). That was the approach I was trying to use, to link in the generated jar, from java_proto_library.

from rules_protobuf.

It sounds like a frustrating experience to manually curate a classpath.

The main output of a java_proto_library is the same as a java_library rule: a jar containing the compiled classes. Internally, java_proto_library calls java_proto_compile, and uses the output of that (a srcjar) as input to a java_library rule via the implicit '%{name}.pblabel. You should be able to get the classfile jar with//path/to/package:fooand the srcjar as//path/to/package:foo.pb` (try bazel building both from the command line).

But there are a number of java library dependencies (maven jars) also that go into that java_library rule. So I'm guessing that eclipse needs to know about these also.

Which means you have to go and hunt that down, and manually add these to your curated classpath. Not fun.

I'd encourage you to give e4b a try. If it works at all, it should work with this repo.

from rules_protobuf.

Tried installing e4b; didn't work; filed bazelbuild/eclipse#10

from rules_protobuf.

Forgive me; I'm having trouble following your description.

$ blaze build //path/to/package:foo  # works
$ blaze build //path/to/package:foo.pb  # fails

$ ls genfiles/path/to/package/
_ijar
foo.pb.descriptor_set
foo.pb_java.jar
foo.pb_java.srcjar
$ jar xf genfiles/path/to/package/foo.pb_java.jar && tree path
path/
  └─to/
      └─package/
          └─Foo.java
          └─FooOrBuilder.java
          └─FooOuterClass.java

Here's where I get lost. By following your description, I would expect these to be .class files. But they are .java files. What am I doing wrong?

from rules_protobuf.

1. It looks like you are using blaze, not bazel. I'm not a googler so I don't know if there are incompatibilities of using bazel within blaze. I'm used to seeing bazel-genfiles. But it looks pretty similar, so I'm guessing the bazel team has worked this out. YMMV.
2. You are right, I forgot that the name of generated sourcejar file now has the ctx.label.name in it. The correct version as you point out is foo.pb_java.srcjar.
3. Agreed it's confusing that there are two jars there: one foo.pb_java.jar and one foo.pb_java.srcjar. This is because protoc only accepts *.jar filenames with the --java_out option. Conversely, bazel java rules only accept *.srcjar. So there is a cp jar srcjar step that you'll see in most bazel protobuf rules, including this one.
4. The proto_compile rule uses output_to_genfiles = True (largely because the c++ rules require it for header files). But the java_library task outputs to bazel-bin, so you should ls in there to find the class jar.

pcj@carotid:~/github/rules_protobuf*master$ jar tvf bazel-bin/examples/helloworld/proto/libjava.jar
     0 Tue Jan 01 01:00:00 MST 1980 META-INF/
    44 Tue Jan 01 01:00:00 MST 1980 META-INF/MANIFEST.MF
     0 Tue Jan 01 01:00:00 MST 1980 org/
     0 Tue Jan 01 01:00:00 MST 1980 org/pubref/
     0 Tue Jan 01 01:00:00 MST 1980 org/pubref/rules_protobuf/
     0 Tue Jan 01 01:00:00 MST 1980 org/pubref/rules_protobuf/examples/
     0 Tue Jan 01 01:00:00 MST 1980 org/pubref/rules_protobuf/examples/helloworld/
   273 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc$1.class
  1739 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc$GreeterBlockingStub.class
  1949 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc$GreeterFutureStub.class
  1804 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc$GreeterImplBase.class
  1863 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc$GreeterStub.class
  2076 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc$MethodHandlers.class
  3047 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/GreeterGrpc.class
  1117 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloReply$1.class
 11812 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloReply$Builder.class
 10530 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloReply.class
   316 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloReplyOrBuilder.class
  1129 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloRequest$1.class
 15507 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloRequest$Builder.class
 12459 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloRequest.class
   763 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloRequestOrBuilder.class
   895 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloWorldProto$1.class
  2812 Tue Jan 01 01:00:02 MST 1980 org/pubref/rules_protobuf/examples/helloworld/HelloWorldProto.class

from rules_protobuf.

Strange because the .pb target should exist:

pcj@carotid:~/github/rules_protobuf*master$ bazel build examples/helloworld/proto:java.pb
INFO: Found 1 target...
Target //examples/helloworld/proto:java.pb up-to-date:
  bazel-genfiles/examples/helloworld/proto/java.pb_java.srcjar
INFO: Elapsed time: 0.094s, Critical Path: 0.00s

from rules_protobuf.

Thank you so very much. You are correct I was looking in the wrong place. I'm not sure how I missed bazel-bin; I'm sure I looked there first. But indeed, my jar is there, now.

Re: blaze vs bazel. Oops, you caught me. I'm so used to typing blaze at work, but I am indeed using bazel at home. I typed out that bash and its output directly; my target isn't named foo.

from rules_protobuf.

My project builds now. The solution was to add blaze-bin/path/to/package/libfoo.jar and external/com_google_protobuf_protobuf_java/jar/ to by build path.

Thank you again.

from rules_protobuf.