intellij: Dependency Library locations dont have source jars

E.g.

<component name="libraryTable">
  <library name="grpc-core-1.7.0-ijar_b557f595">
    <CLASSES>
      <root url="jar:///private/var/tmp/_bazel_michael.schiff/dcad08dfc7b1c329418c14a917d7f378/execroot/__main__/bazel-out/darwin-fastbuild/genfiles/external/org_pubref_rules_protobuf/java/_ijar/grpc_compiletime_deps/external/io_grpc_grpc_core/jar/grpc-core-1.7.0-ijar.jar!/" />
    </CLASSES>
    <JAVADOC />
    <SOURCES />
  </library>
</component>
-> % ls /var/tmp/_bazel_michael.schiff/dcad08dfc7b1c329418c14a917d7f378/execroot/__main__/bazel-out/darwin-fastbuild/genfiles/external/org_pubref_rules_protobuf/java/_ijar/grpc_compiletime_deps/external/io_grpc_grpc_core/jar/
grpc-core-1.7.0-ijar.jar

compared to what is found in bazel-repo

-> % ls /private/var/tmp/_bazel_michael.schiff/dcad08dfc7b1c329418c14a917d7f378/execroot/__main__/external/io_grpc_grpc_core/jar/
BUILD.bazel                 grpc-core-1.7.0-sources.jar grpc-core-1.7.0.jar

Is there a reason we should not be using the repo location for libraries?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 34 (14 by maintainers)

Commits related to this issue

Most upvoted comments

The root cause of these problems was artifacts derived from external workspaces being improperly resolved, triggered by a change to the bazel output directory structure combined with some old compatibility code in our aspect.

Should be fixed for the next release (at least, the issues with that sample project appear to be fixed)

Ignore that last comment, it does look like there’s a problem copying the source jar locally – I’ll take a look.

Ah, that makes sense then. The fix is not in the latest release, but will be in the next one (v2018.12.03).

I can’t reproduce any issues with that exact same project, but I don’t know how you’re building the plugin.

I’d wait and see if it’s still broken in the next release uploaded to JetBrains’ plugin repo (scheduled for next Friday).

The IJ plugin uses a different API to intercept and display sources. One that’s marked as being removed in 2019.

I’ve read that javadoc and it actually makes perfect sense. But are there actually any plans on supporting library indexing? For example, may be it’s possible to have a separate lib output folder which won’t be reshuffled after every blaze build.