Implement AutoDeps for BEF

[plaird]

We have talked internally about having a feature to automatically track API modules and offer to add the api target to compile_deps, and impl target to runtime_deps. This ticket will track that.

Wix demo'd a similar tool for IJ at BazelCon 2019. If they open source it we can take a look at how they did it. We probably need the user to add a hook into the Bazel workspace to generate a list of class->dep mappings. We need the class to appear even if the package was not imported into BEF.

Here is a discussion that documents some existing work that may help with this:
https://groups.google.com/u/1/g/bazel-discuss/c/W38EuyqEmvM/m/h0Yi3Zm0AAAJ

[beginningineer]

Hi, @plaird
just viewed Wix demo. I guess "Import class" quickfix may heavy relate on the fact that IJ-Bazel plugin have a sole classpath for the whole workspace (mentioned in #29 (comment)).
In terms of BEF architecture (one classpath per BUILD file) I can't imagine how underlying JDT.Core can get an idea that entered symbol is a valid class name and provide a fix with FQN.

[plaird]

@beginningineer good question. I am thinking every Eclipse Bazel project will have second Eclipse classpath container "Bazel AutoDeps Classpath Container" that will contain the candidate list of deps. This will allow the Java Editor of JDT to see everything in the candidate list. The trick will be figuring out when a dep should be added to the Bazel Classpath Container (the BUILD file). Bazel Query can tell us that, but there is some real work there to implement.

[plaird]

Progress has been made on this. While the Global Search Classpath feature #161 is experimental and still needs a lot of refinement, I believe it is the first step towards Autodeps.

Details of the Global Search Classpath can be found in #161 and also this doc: https://github.com/salesforce/bazel-eclipse/blob/master/docs/using_the_feature_classpath.md#global-search-classpath

[plaird]

This feature is getting closer. Just after BEF 1.5.0 was released, I added a hook into JDT's classpath fix extension point. This is the JDT UI scheme for presenting the user with ways to fix the classpath. With #357 we now hook into that UI, and correctly determine which Bazel label (e.g. @maven//:org_slf4j_slf4j-api) needs to be added to the package.

What remains is figuring out what target to add the label to, which has two tasks:

Figure out what file changed.
This might have been easy, but the Eclipse extension point currently does not pass the filename that has the broken classpath. It only passed the project, and the missing type. The filename is necessary to determine what target(s) are affected. I tried an experiment with a resource change listener, but that only works if the user saves the file. The ClasspathFixProcessor extension point in Eclipse is activated even if the user does not save the file, so this is a problem.

Figure out what targets in the package use the changed file.
Right now BEF does not have great record keeping of the individual targets within the package. It has a little, but not enough. BEF 1.6 will focus on adding more bookkeeping into BEF to track more details about each target in a package. This is necessary for several reasons, but will especially help us compute the right target(s) for buildozer to add the dep.

[plaird]

Once this feature is done, we could take dependency management much further with something like Fasten which does detailed call-graph dependency analysis. I tried to do a quick POC with it, but hit some issues. Because we have resolved the classpath and source file folders already to feed JDT, it should be somewhat easy to hook up Fasten.

[plaird]

This solution can also be expanded to support jars not already in the workspace. This would require calls up to Maven central. The m2eclipse team is implementing such a feature right now in eclipse-m2e/m2e-core#623