As a BEF user importing a large Bazel workspace
I would like the BEF to use perf optimizations such as caching to speed up the import as much as possible
Such that the workspace is correct with no build errors at the end of the import

REVISED: we have already done some work on this ticket, specifically enabling some caching as much as possible. The remaining work is believed to be ordering the Bazel packages in reverse dep order on import. This will allow each classpath to be computed just once.

Example:

Given a workspace with 4 targets A, B, C, D. The notation -> means 'depends on' and can be a compile or runtime dep.

A -> B
B -> C
B -> D

The import order would be either:
D, C, B, A
C, D, B, A

Currently a src/main/java class can reference org.junit.Assert, for example.
The reason is the classpath container is not adding the TEST attribute to dep libs that come in via java_test targets in the project.

This is not a simple fix beause currently the classpath container is taking the union of all targets in the BUILD file (using the :* wildcard) and then handling that off to the Bazel command line to generate all aspect json files at once for all the BUILD targets. That command returns a number of aspect json files, but we cannot distinguish which ones were generated due to java_test targets and which ones are from java_library and java_binary targets.

We will need to refactor the way we run the Aspect command line. We need to generate the list of Bazel targets in a BUILD file, and then individually ask for each set of dep aspects per target. This will slow things down.

Repro:

• in any main source jar, add an import to org.junit.Assert which should not resolve
• open Build Path UI view
• click on Libraries tab, open the Bazel Classpath Container node
• open the junit.jar node
• see that the "Visible only for test sources" is marked no, it should be yes

As a BEF user
I would like to have smart editor support for BUILD files

Background:
Given resource constraints on BEF, BEF is mostly just trying to integrate Bazel into existing JDT tooling (oriented around Maven and Gradle). But this is the highest value feature for Bazel specific tooling. It would be really nice to offer some editor support for BUILD files.

Spike tasks:

• Look at what IJ and VSCode integrations are doing, including integration with Buildifier.
• Assemble a feature list of what BUILD editor should support
• Spend a couple of days to see how far you can get with it, what challenges do you hit
• Create follow up issue(s) to track the implementation and add to the appropriate Project (Major Features, 1.1, etc) https://github.com/salesforce/bazel-eclipse/projects

Feature ideas:

• Syntax highlighting
• Error and Warning markers
• Code templates (snippets) eg. type java_ and then Ctrl-Space, and snippet completions for java_library, java_test available
• Formatter rules
• Outline view support
• Refactor deps attribute into a standalone list
• Unused variables

Initial launch of 1.0.0 was only tested on Mac. We need to follow on with Linux support. Currently it fails to install with error:

Missing requirement for filter properties ~= $0: Bazel Eclipse Core Plugin 1.0.0.release (com.salesforce.bazel.eclipse.core 1.0.0.release) requires 'org.eclipse.equinox.p2.iu; org.eclipse.swt.gtk.linux.x86_64 [1.0.0.release,1.0.0.release]' but it could not be found

As a BEF user
I would like to navigate into code bases that aren't imported as projects into the Eclipse workspace
Such that I can see the source jar for each external jar (e.g. slf4j, spring framework)
Such that I can see the source jar for each internal jar (i.e. built by the Bazel workspace by a package not imported into the Eclipse workspace)

As a BEF user installing the feature
I would like the process to be intuitive
Such that I do not have to click any non-default options in the install wizard

Background:
Currently, the user has to uncheck 'Group items by category'

We have a set of facades that orchestrate most of the real work done in the core plugin. When running in inner Eclipse, these facades are backed with integrations into Eclipse APIs. When running in functional tests, these facades are backed by mock impls.

Right now the facades are wired up in a central point - BazelPluginActivator. It was a convenient place to put them, but isn't really the right place for them to be. Figure out a better alternative.

As a BEF user
I would like to import a logical Java project that has multiple BUILD files
Such that the Eclipse project represents the logical project (my-foo-library)
Such that there are multiple BUILD files found in the source directories

Background:
The initial BEF implementation is restricted to so-called 'conforming' Java packages.
https://github.com/salesforce/bazel-eclipse/blob/master/docs/conforming_java_packages.md

But there are likely many Java projects in the wild that have multiple BUILD files for a single Java project. Wix promotes the 1:1:1 model, which is "1 build target in 1 build file for 1 Java package".
https://medium.com/wix-engineering/migrating-to-bazel-from-maven-or-gradle-part-1-how-to-choose-the-right-build-unit-granularity-a58a8142c549

This ticket will allow those projects to be imported as a single Eclipse project. It will require some facility (a marker file in a directory, Project Views #5 ) to flag what constitutes a 'project' in the Bazel workspace.

This feature will need to consider having a solution for the multiple classpath requirement as covered in this issue: #23

As a BEF user importing a large Bazel workspace
I would like to have a file created by a colleague that lists all the packages most often modified by my team
Such that packages that I don't ever care about are not imported into the Eclipse workspace
Such that I don't have to manually click a long list of checkboxes on import.

Background:
We could use the IJ plugin project view file format to allow team members to share a common set of packages that should be loaded into the IDE at import.

Note that the project view file format has at least 10 possible sections. This ticket would just implement the directories and targets sections.

https://github.com/bazelbuild/intellij/blob/194f34b0690827918356eab5ae84fe85c8f6c50c/base/src/com/google/idea/blaze/base/projectview/section/sections/Sections.java#L27

As a BEF user
I would like the UI to be responsive during imports and
I would like the import process to not fail with an "Invalid thread access" error

While importing a large workspace today, import failed with 'Invalid thread access'. This points to a known improvement we wanted to make:
https://github.com/salesforce/bazel-eclipse/blob/master/plugin-core/src/main/java/com/salesforce/bazel/eclipse/config/BazelEclipseProjectFactory.java#L116

As a BEF user with protobuf and/or grpc-java packages
I would like to have BEF understand how to load the Source Folder for the generated types
Such that the consuming code does not show as red squigglies in JDT

Example:
//projects/services/service has a Java library target

which depends on

//projects/protos/api which has grpc-java targets (java_grpc_library, proto_library)

We have some functional tests in plugin-core, but not enough to protect against regressions.

• figure out what big areas lack coverage
• implement tests to plug the holes

Code coverage reporting is available in Eclipse SDK, details: https://github.com/salesforce/bazel-eclipse/wiki/BEF:-Code-Coverage

Issue #5 adds initial Project View support for the "directories:" section. Currently, all paths listed in that section must be valid Bazel packages (contain a BUILD file).

Add support for specifying only an ancestor path, and auto-discovering the packages below.

For example, given the Bazel workspace:
a/b/c/BUILD
a/b/d/BUILD
a/b/e/f/BUILD
a/z/BUILD

In the Project View's directories section, it should be possible to specify the path "a/b", which should result in the first 3 packages above to be imported.

As a BEF user with some packages that take a long time to build
I would like to see build errors/warnings populate the Eclipse Problems view as they happen
Such that I don't have to wait for my packages with long build times to complete before seeing them

As a BEF user
I would like to work on multiple Bazel workspaces at the same time
Such that my single Eclipse workspace has Eclipse projects open from the multiple Bazel workspaces
Such that nested workspaces in a Bazel workspace can also be imported

Background:
We currently create a synthetic Eclipse project to represent the Bazel Workspace. This includes the WORKSPACE file. To support multiple Bazel workspaces, there are many code locations that assume there is a single Bazel Workspace - that code will need to be smarter.

This is the Issue for the general capability of multiple Bazel workspaces. Additional variants include:

• nested workspaces - inside of subdir of the outer Bazel workspace, there is a WORKSPACE file and a fully contained workspace inside
• local_repository - reinterpret as a nested workspace
• external workspace - optional to bring in git_repository repo into the Eclipse workspace

After implementing the basic feature, consider filing follow up issues for the variants.

As a BEF user
I would like to import Java packages that don't adhere to Maven conventions
Such that I can have my java code in directory [package_dir]/sources/com/acme/apple/

Background
To simplify early life with BEF, we have instituted restrictions on the layout of packages.
We require them to be Conforming, see //docs/conforming_java_packages.md

This issue will just solve the non-standard directory layout problem. Acceptance criteria is:

• main source is located in: [package_dir]/mysources/com/acme/apple/
• bundled resources are located in: [package_dir]/myextrafiles/com/acme/apple/
• test source is located in: [package_dir]/test/com/acme/apple/
• BUILD file is located here: [package_dir]/BUILD

We have other tickets that will resolve the multiple-BUILD-file problem, and the multiple-classpath-within-a-BUILD file problem.

Related:

• #8
• #24

As a BEF user
I would like to create a Bazel target launcher for my java_web_test_suite tests (Selenium)
Such that I can launch the test from Eclipse
Such that I can debug the test from Eclipse

When importing a project the import throws the following message:

Unresolved compilation problem:
The constructor JSONTokener(FileInputStream) is undefined

The eclipse log file is not showing any errors and the bazel command executed is also finishing successfully. (also when tried on the command line)

As a BEF user
I would like to import my Bazel workspace that uses maven_install to retrieve Maven deps
Such that Eclipse JDT is properly provisioned with the correct classpath for each Java project

Background
Currently BEF has only been tested with Maven deps sourced with the native.maven_jar workspace rule. Test/fix it to also work with maven_install.

https://github.com/bazelbuild/rules_jvm_external

Internally at Salesforce we are just now migrating to maven_install at the time of this Issue being filed. Given the use of Aspects to derive dep file system path information, I am hoping this will be an easy thing to support.

Thanks to Matthias Schett from the community for requesting this.
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/bazel-eclipse-discuss/87Va4oGscgM

As a BEF user with a particular Bazel workspace
I would like to import the workspace entirely
Such that there is a way to handle multiple Bazel packages with the same leaf path name

Example:
Consider a Bazel workspace with this structure:

//projects/path1/apple-api/BUILD (java_library target here)
//projects/path2/apple-api/BUILD (java_library target here)

Right now you cannot import the entire workspace, you have to choose to only import one of the apple-api packages. This is because we name the Eclipse project with the leaf node of the path (apple-api). An Eclipse workspace cannot contain two projects of the same name.

As a BEF user
I would like to run JUnit tests for my Bazel Java projects as I would Maven Java project
Such that I can choose to Run As -> JUnit test
Such that the JUnit view displays the test results

Background:
Initial investigation indicated that the current Eclipse IDE infrastructure for JUnit is a bit coupled to plain Java/Maven ways of doing things. To get BEF 1.0 out, we kept things simple and supported running tests via our Bazel launcher:

https://github.com/salesforce/bazel-eclipse/blob/master/docs/using_the_feature_launching.md

But it would be nice to have standard JUnit integration working.

As a BEF developer
I would like to know that I haven't broken installs from BEF updatesite
Such that we have an integration test that installs the feature from .zip

We have a small configuration issue. Fix should be easy. In my inner eclipse Error Log view, I am seeing this warning:

Commands should really have a category: plug-in='com.salesforce.bazel.eclipse.core', id='com.salesforce.bazel.eclipse.launch.shortcut.debug', categoryId='org.eclipse.debug.ui.category.debug'

Somebody else had this issue, and fixed this for another plugin as explained here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=181347

Creating a distinct issue from Issue #10 even though they are tracking similar issues, to make this bug more visible to new users. It is a benign exception but seems to be common when installing from updatesite .zip file.

Root exception:
java.lang.IncompatibleClassChangeError: Class ch.qos.logback.classic.LoggerContext does not implement the requested interface org.slf4j.ILoggerFactory
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:270)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)
at com.gradleware.tooling.toolingclient.internal.DefaultToolingClient.(DefaultToolingClient.java:38)
at com.gradleware.tooling.toolingclient.ToolingClient.newClient(ToolingClient.java:41)
at org.eclipse.buildship.core.CorePlugin.createToolingClient(CorePlugin.java:190)
at org.eclipse.buildship.core.CorePlugin.registerServices(CorePlugin.java:154)
at org.eclipse.buildship.core.CorePlugin.start(CorePlugin.java:117)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:782)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:775)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:732)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:1005)
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:357)
at org.eclipse.osgi.container.Module.doStart(Module.java:584)
at org.eclipse.osgi.container.Module.start(Module.java:452)

As a BEF user with a project that has java_lite_proto_library or java_proto_library rules
I would like to stay in the IDE while iterating on the .proto files
Such that consuming projects are immediately notified of changes and build breaks announced in Problem View

See issue #37. That issue is closed, and enabled BEF to add the generated libs from proto rules to the classpath for consuming projects. That works well for situations where the .proto files are not changing.

But that work did minimal effort to allow .proto packages to be effectively iterated on within BEF. Such as changing the .proto, fixing up affected consumers, etc. That is what this issue is all about. Much lower priority.

For example, notice that currently the consuming project does not have a Project Reference to the project that has the proto rule. That should be fixed.

As a BEF user
I would like the BEF installable download to be signed
Such that I don't get a worrying warning during install

Background
During export, there is an option to sign the jar. Investigate if we can obtain the authority to sign as Salesforce (seems troublesome, but perhaps).

As a BEF user
I would like to use Eclipse+BEF on my Windows machine
Such that all the features work as expected

Background:
I am filing this having only tested on Mac and Linux. I assume the BEF will need to be updated to support Windows (path constructions, etc) but I don't know the scope of work right now. I will need to get a Windows machine to do the assessment.

This issue is an open forum for collecting thoughts, questions, and requests for anything related to Language Servers. At this time (Dec 2019), the BEF authors (Salesforce) has no plans to produce a language service server from this code base.

However, the code is structured into multiple plugins to make such an effort possible (and for other reasons). The Core plugin handles all of the direct Eclipse API integration (not reusable for a language server) but the rest of the plugins are not dependent on Eclipse APIs.

See also:

• https://github.com/eclipse/eclipse.jdt.ls

As a BEF user
I would like JDT warnings to appear in the Eclipse Problems View
Such that I am not surprise when I open a file in the Java editor and see warnings

Background:
Currently, the Problems View is populated by errors scraped from the Bazel command line build of the packages. But this loses the warnings that JDT generates.

As a BEF user with a Bazel package with multiple Java targets
I would like the classpath provided to JDT to be accurate
Such that import statements will fail if the BUILD target does not have the dependency

Example
Create two java_library targets in a BUILD file. In LibA, make a dependency on some open source library. In LibB, do not have that dep listed. In a Java file that is brought into LibB, use the API for the open source library. JDT will not complain. The command line build and Eclipse Problems View will show the error though.

Background:
Right now the classpath computed for the Eclipse Java project by the Bazel Classpath Container is the union of all Java targets in the BUILD file. This can lead to issues where JDT will be happy, but the command line build (and Eclipse problems view) will have errors. JDT (seems like) supports only a single classpath for an Eclipse Java project (with two divisions - main and test).

Possible outcomes of this ticket:

• Discover that supporting multiple classpaths in a single Eclipse Java project is already possible, implement it, and celebrate
• Discover that JDT would only need a few minor changes to support this, file those with the JDT team, and hope for resolution
• Conclude that this will never be possible, and write up a one-pager about it in the docs

We inherited the Bazel build rules for feature, plugin, and updatesite from the original Google project. When I split the feature into multiple plugins, it required changes to the rules. I put some effort into it, but it wasn't a high priority to fix them. Exporting the feature updatesite.zip from the Eclipse SDK is an ok solution at this early point in time.

The Bazel build is still used by CI for compiling the sources and running our unit/functional tests. But the actual packaging of the feature is left to Eclipse SDK. For iterative development this is fine because our team is able to just Run.. or Debug... the feature and the SDK auto packages the feature/plugins.

But in the long term, we should figure this out:

• invest in reviving the Bazel rules
• switch to Tycho for command line build

As a Bazel Eclipse Feature user
I would like to use the BEF to develop my XYZ code (non-Java) in my Bazel workspace
Such that import of my Bazel workspace creates Eclipse projects for my BUILD file(s) with XYZ targets
Such that I can launch XYZ applications
Such that I can launch XYZ tests

Background:
The primary motivation for implementation of the BEF by the project authors (Salesforce) has been supporting Java teams. Currently this ticket is a request for comments for teams that would like to use BEF but use some language other than Java.

Please comment on this issue if you have non-Java projects that you would like to use with BEF. This issue is just a gathering point for discussion. Additional issues will be filed if/when any works begins on investigation/implementation of support for other languages begins.

As a BEF user
I would like to change a BUILD file with updated dependencies
Such that the classpath containers in the Eclipse projects generated by BEF are updated

As a BEF user
I would like to import a few more projects from my Bazel workspace into my existing Eclipse workspace
Such that the classpath containers in the existing Eclipse projects generated by BEF are updated
Such that project references are correct

Background:
Currently we do a big cycle of running Aspects when projects are imported
We need to flush the Aspect cache and flush the computed classpath of the affected Eclipse projects when a user changes a BUILD file, or when a user imports more projects.

As a BEF user
I would like to have a smart editor for WORKSPACE files

Background:
Currently, since WORKSPACE file editing is presumed to be a low frequency activity, this feature is not a high priority for BEF.
Also there are complications such as many WORKSPACE files load() .bzl files, so they do not stand on their own.
See #189 for thoughts about .bzl file editing.

As a BEF user with a Bazel install that is too old to work correctly with BEF
I would like to be notified when Eclipse starts up
Such that I get a helpful warning message if my Bazel executable is too old

Background
Right now the BazelVersionChecker only runs if you are in the Preferences->Bazel view.
https://github.com/salesforce/bazel-eclipse/blob/master/plugin-libs/plugin-command/src/main/java/com/salesforce/bazel/eclipse/command/internal/BazelVersionChecker.java

As a BEF user with an existing Bazel workspace imported into Eclipse
I would like to add more packages from my Bazel workspace as Eclipse projects
Such that I don't have to recreate the entire Eclipse workspace and re-import my new preferred set of packages

Repro:

1. Create a java_test rule in a BUILD file with a valid junit test

2. do NOT add hamcrest as a dep

3. add this line to the test method:

   org.hamcrest.core.StringContains.containsString("test");

4. bazel test //... (your test should succeed)

5. in BEF, open the test .java file in the editor, and the hamcrest line will be red squigglied

There are some implicit deps that the command line test runner adds to the classpath, that BEF needs to imply for packages that contain java_test targets. Figure out what they are, and add them.

This started as a logback issue, but now it is something different. I think what is happening is once we start invoking Bazel commands, and hook stdout and stderr for that, our logging to outer Eclipse no longer works.

====

We revamped the logging for the feature. But on my machine, file logging is not working correctly. I tried a bunch of different things, but in the end I found a clue that suggests a load ordering problem.

I have added this check to our Eclipse logging facade:

bazel-eclipse/plugin-core/src/main/java/com/salesforce/bazel/eclipse/EclipseLoggerFacade.java#L153

And it indicates the logback is indeed in the classpath, but for some reason my log factory was initialized too early or in a different plugin such that logback was not found:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

com.salesforce.bazel.eclipse.core: EclipseLoggerFacade could not configure file (INFO, DEBUG) logging. LoggerFactory is of type [class org.slf4j.helpers.NOPLoggerFactory] but needed [ch.qos.logback.classic.LoggerContext] to configure the file log. The class ch.qos.logback.classic.LoggerContext is NOW available in the classpath, which means there was a startup loading issue. The class wasn't there when logging was initialized. See bazel-eclipse/docs/dev/logging.md for more details.

Issue #5 adds initial Project View support (bazelproject file), but supports only the "directories:" section. Add support for the "targets:" section also.

At the same time, remove the logic that writes targets to Eclipse preferences: https://github.com/salesforce/bazel-eclipse/blob/master/plugin-core/src/main/java/com/salesforce/bazel/eclipse/config/BazelEclipseProjectSupport.java#L76

Project View: http://ij.bazel.build/docs/project-views.html

As a committer to BEF
I would like to have CI coverage for PRs and merges to master
Such that I can be sure that regressions have not been introduced

Background:
At launch (Dec 2019), this project will only have CI coverage inside the walls of Salesforce. Implement a public option.

As a BEF user with colleages that use IntelliJ
I would like to be able to share workspace IDE config with them
Such that the config is persisted in a shared config file

Background:
Project Views are implemented in IJ.
In #5 and #68 we implemented the ability to share directories and targets via Project View files.

This ticket will fill out the implementation:
https://github.com/bazelbuild/intellij/blob/194f34b0690827918356eab5ae84fe85c8f6c50c/base/src/com/google/idea/blaze/base/projectview/section/sections/Sections.java#L27

As a BEF user
I would like to have smart editor support for BUILD files

Background
Editing BUILD files is somewhat common for evolving Bazel projects. It would be helpful for users to have editing support for these files.

We have a tactical spike to assess existing ideas and level of effort for building a BUILD file editor. That ticket tracks the effort by the Salesforce team to investigate BUILD file support: #21

This issue is a higher level tracking issue for ideas and general comments about BUILD file support from the community.

We have four major refactoring ideas/goals.

1. Bloated Core Plugin (status: COMPLETED)
The intent of the Core plugin is to be the integration layer to/from Eclipse APIs. The other plugins have no exposure to the Eclipse APIs, which make them reusable (if anyone ever wanted to build a language server) and more easily testable.

But over time, the Core plugin code base has grown and includes too much. The classpath container is a perfect example. About half of that file has nothing to do with Eclipse.

2. Code share with Language Server effort (status: MOSTLY DONE, defer rest to #188)
Another Salesforce team is working on a language server. They are using BEF code and we would like to share work.

bazel-jdt-ls

Other build tooling projects could benefit as well. The isolation work has been completed internally to the BEF repo. The top-level bzl-java-sdk directory is the result of this. Splitting bzl-java-sdk into a new GitHub repo is the intent, but since we are doing heavy development on it in conjunction with BEF I am resisting that move for now. With Git submodules, we could link them, but that just feels like a pain at this stage of development. I am thinking the move out of bzl-java-sdk will occur at the end of the 1.x release line. Issue #188 will track that final step.

3. Non-java projects (defer to Issue #19)
We plan to support other languages than Java in the future. I envision have a set of plugins, like:

• plugin-java
• plugin-c
• plugin-scala
• plugin-go

that would adapt the Bazel rules for each language into Eclipse projects. I have doubts that this will ever happen beyond Java, and maybe C. See #19

4. Bazel Java SDK (status: COMPLETED)
The idea of the non-Core plugins is to keep most of the code base free of Eclipse dependencies. One of my hopes it to isolate it as a general purpose SDK for anyone who wants to create Bazel build tooling in Java.

As a new BEF user
I would like to have some sample Bazel workspaces to try out the BEF

As a BEF developer
I would like to have Bazel workspaces with various characteristics
Such that I can manually test my changes to BEF

As a BEF user that has hit a possible bug
I would like an easy way to submit a repro test case
Such that I don't have to build a test Bazel workspace from scratch
Such that I can send a PR to augment an existing test Bazel workspace

I don't know if this would be better to have as a separate repo, or as a subdirectory in this repo e.g. //samples

Example Characteristics:

• basic Java packages with some inter-dependencies
• two packages with Java rules with the same name 'apple-api' at different paths //libs/path1 //libs/path2
• non-conforming Java packages
• a tool to generate an enormous workspace for scalability testing (10,000 packages)
• deeply nested package path //a/b/c/d/e/f/g/h/i/j/k/l/m/n/...
• etc

Currently we have 17 build warnings in outer Eclipse, such as:

• 'com.salesforce.bazel.eclipse.abstractions' is missing version constraint information
• A plug-in manifest must contain at least one extension or extension point
• Referenced identifier 'com.salesforce.bazel.eclipse.launch' in attribute 'category' cannot be found

Update the import code to always throw an NPE or other runtime exception.
Someplace in BazelClasspathContainer is a good spot.

Currently that causes import to fail with cryptic "Invalid thread access" error popup.
The popup itself comes from BazelImportWizard.performFinish()

As a BEF user
I would like to configure my launcher (java_binary, junit) with more configuration than what is possible today

Details
Look at the IntelliJ Bazel launch config UI and the Eclipse Java Launch Config for inspiration. Obvious things that are missing are:

For apps (main methods):

• java arguments (for ex system properties, and argument passed directly to the java executable)
• program arguments
• environment variables?
• bazel flags

For tests

• java args
• bazel flags
• others?

Repro (ish):

1. have JDK11 installed on your machine
2. launch Eclipse with BEF installed
3. import a valid Bazel workspace with Java packages
4. open any of the Java files
5. will see JDT red squiggly errors in the editor (but not Eclipse problems view)

"The method foo(String) from the type XYZ refers to the missing type String"

Workaround:

1. right click on project in the Package Explorer
2. Build Path -> Configure Build Path
3. click on the Libraries tab
4. click on the JDK 8 library, and then Remove
5. click on the Classpath node, then Add Library...
6. JRE, then your system JDK 11, then Finish
7. Red squigglies will go away

As a BEF user
I would like to right click on my Java file in the Package Explorer
Such that I have an option to Run As -> Bazel Target

Background:
(Salesforce internal) we once had this working via a class plugin-core/.../launcher/BazelJunitTargetLaunchShortcut.java in the old bazel-eclipse repo (go back to commits in Oct 2019). It wasn't working before we cut to the public repo, so it was removed temporarily.

When working this ticket, consider that we also want to be able to run 'all tests' in one action using the right-click UX. Either incorporate that into this work, or create a follow up Issue to address that.

As a BEF user
I would like to manually configure certain aspects of an imported Bazel Java project
Such that my IDE experience is tailored to my development needs
Such that I can right click on the Bazel Eclipse project in the Project Explorer and choose "Properties -> Bazel" and have UI for this configuration

Targets:
Currently when we import, we keep the import process simple and activate all Bazel Java targets in the BUILD file. This can be seen in the file:
[Eclipse workspace dir]/[project name]/.settings/com.salesforce.bazel.eclipse.core.prefs

You will see an entry like this that was written by the BEF import machinery:
bazel.target0=//projects/libs/apple/apple-api:*

Because the wildcard target is set, whenever Eclipse issues build directive to this Eclipse project, we run a bazel build of all targets:

bazel build //projects/libs/apple/apple-api:*

However, the BEF builder is better than that. If you instead replace the prefs line with these:

bazel.target0=//projects/libs/apple/apple-api:apple-api-lib
bazel.target1=//projects/libs/apple/apple-api:apple-main

it will instead run a project build like this:

bazel build //projects/libs/apple/apple-api:apple-api-lib //projects/libs/apple/apple-api:apple-main

I still think the wildcard target is a reasonable result of the import process. But we should provide UI to let the user scope that down. Imagine if there was a third target in that package that was not typical and was time consuming to build.

See also #73 which could be thought of as the simple solution this, and this Issue will work on the longer term solution.

Bazel Tags
Another element to think about when designing this feature is tag configuration in some way. We don't yet use tags in any significant capacity at Salesforce, but we plan to in the future. If others in the public community has input on what would be good to support wrt tags, we would love to hear it!

Complications
This UI will get trickier as soon as we start allowing multiple BUILD files in a single Eclipse project, see this issue: #24