Buried logs // directory permissions issue with Lombok

[venantius]

Description of the problem / feature request / question:

I'm working on building a library that has a compile-time dependency on Lombok. I've been able to successfully get this working with some projects, but with others Lombok runs into issues when it tries to create and use dummy files. As part of this, it's supposed to dump a stacktrace (per the code here), but the only thing that actually gets surfaced to me is something like this:

warning: Can't force a new processing round. Lombok won't work.ERROR: /Users/william_jarvis/airlab-beta/repos/treehouse/projects/omnes/omnes-clients/BUILD:9:1: Java compilation in rule '//projects/omnes/omnes-clients:omnes-clients' failed: Worker process sent response with exit code: 1.

I suspect that this will turn out to be an issue relating to Lombok trying to create files inside of Bazel's build directories and not having the appropriate permissions, but in order to confirm that hypothesis I'd like to try to uncover the stacktrace first. I've tried perusing the various logging options that Bazel surfaces but can't seem to figure out how to find where the full stacktrace is getting logged. Could I get some guidance on where I should be looking for this?

Thanks!

Environment info

OS Sierra 10.12.3
release 0.4.4-homebrew

Anything else, information or logs or outputs that would be helpful?

(If they are large, please upload as attachment or provide link).

I also have a ticket open with the Lombok maintainer about this: projectlombok/lombok#1290

[cushon]

+@philwo

The full error is shown if you disable workers with bazel build --strategy=Javac=local ...

[venantius]

Hmmm. I knew Bazel was using the Java9 compiler and was hoping I could get around this by specifying the source as 1.8 using javacopts, but that didn't seem to work. Is there a short term fix I can deploy that uses JDK8 for the compilation engine?

[venantius]

I'm okay with closing this ticket since @cushon answered my question, but I do think the docs as they currently are don't necessarily make it obvious how to access these logs, and my expectation was that there would just be a directory full of logs that I could go check out on the filesystem.