Comments (7)
Over a series of commits, this feature was implemented.
User impact:
- If your Bazel workspace has the following command option: explicit_java_test_deps=true, BEF will NOT add the implicit test runner jar to the JDT classpath
- If your Bazel workspace has the following command option: explicit_java_test_deps=false (or unspecified, false is the defaut), BEF will add the implicit test runner jar (Runner_deploy-ijar.jar) to the JDT classpath. This will prevent JDT from adding red squigglies to your test classes where junit/hamcrest classes are referenced.
To see what entries the BEF has supplied to the JDT classpath for a project, do the following:
- open your imported project's node in the Package Explorer
- open the Bazel Classpath Container node
- you will see the list of jars added to the JDT classpath below that node
Implementation Details:
- Mostly encapsulated here: https://github.com/salesforce/bazel-eclipse/blob/master/plugin-core/src/main/java/com/salesforce/bazel/eclipse/classpath/EclipseImplicitClasspathHelper.java
from bazel-eclipse.
This is caused by a known issue in Bazel. The issue can be 'fixed' by setting this in your .bazelrc and running bazel test in your command line build:
test --explicit_java_test_deps=true
Setting that property eliminates implicit deps, and thus requires hamcrest and junit to be explicitly included in the BUILD file where needed. When you do this, there is an explicit dependency on those libs, and so BEF knows to add it to the project classpath in Eclipse. Then JDT will not show red squigglies in the editor.
This is where the Bazel code has that option:
I didn't track down exactly where those deps are added, but the flag meanders through this code path:
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaSemantics.java#L454
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaSemantics.java#L302
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/java/JavaSemantics.java#L332
https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/bazel/rules/java/BazelJavaRuleClasses.java#L351
from bazel-eclipse.
I have decided that I am going to document this as a known limitation of package import, and not do anything automatic in BEF to correct this configuration. There are workarounds below.
How would BEF know what version of junit or hamcrest libs to add? I feel like Bazel is doing the wrong thing here, and I don't want to build BEF logic to accommodate it. Hopefully explicit_java_test_deps will be set to true by default in the future.
Workaround #1: Fix your BUILD files
I just did this for our internal monorepo, and it takes a little bit of time but I think it is the right thing to do anyway. Add 'test --explicit_java_test_deps=true' to your .bazelrc and fix all of the junit/hamcrest dep issues that arise from a 'bazel test //...'
Workaround #2: Manually fix up your classpath in Eclipse after import
For each affected project, do the following:
- right click on the Eclipse project in the Package Explorer, and click Build Path -> Configure Build Path
- Click on the Libraries tab, and then the Classpath node in the tree
- Click Add External Jars... and locate your version of junit/hamcrest on the filesystem
from bazel-eclipse.
I just requested that we switch the default to disable implicit deps on Bazel discuss:
https://groups.google.com/forum/#!topic/bazel-discuss/COJvRi2W1ok
If that happens, then this becomes a short-term issue and I just doc it like suggested above, or provide a hacky short term solution until people transition to Bazel 3.0. If it looks like implicit deps will remain the default long term, we will need to figure out how to determine which version of these deps to add to each project that needs them.
from bazel-eclipse.
If we implement a hack solution, the way the IJ plugin solves this is by adding the Runner_deploy.jar (actually, Runner_deploy-ijar.jar) to the classpath which is seen in bazel query as:
@bazel_tools//tools/jdk:TestRunner
@remote_java_tools_windows//:java_tools/Runner_deploy.jar
@remote_java_tools_linux//:java_tools/Runner_deploy.jar
@remote_java_tools_darwin//:java_tools/Runner_deploy.jar
with relative path from bazel-bin:
bazel-bin/external/bazel_tools/tools/jdk/_ijar/TestRunner/external/remote_java_tools_darwin/java_tools/Runner_deploy-ijar.jar
But to be correct, this should only be added if: --explicit_java_test_deps=false
from bazel-eclipse.
I am working on adding the hack, but in the meantime have added doc discouraging implicit deps:
https://github.com/salesforce/bazel-eclipse/blob/master/docs/conforming_java_packages.md#recommended-java-conventions
from bazel-eclipse.
added the hack, will write tests next
from bazel-eclipse.
Related Issues (20)
- Support development with lombok
- Support JDT external annotations files HOT 1
- BEF: Implement TestNG support
- Bazel header jars are appearing in the Global Search Index
- BEF: Support the New Project wizard
- LSP gives an exception on the following bazel project HOT 2
- UI Freeze due to heavy logging in UI thread while resolving classpath HOT 1
- Use Maven Wrapper to avoid having to have (the right version of) Maven installed to build this project
- mvn clean => Cannot invoke "org.apache.maven.repository.internal.ModelCacheFactory.createCache(org.eclipse.aether.RepositorySystemSession)" because "this.modelCacheFactory" is null HOT 1
- Java 17 Support HOT 4
- requires 'osgi.bundle; org.eclipse.jdt.ls.core 0.0.0' but it could not be found HOT 3
- ERROR: Unable to find package for @[unknown repo 'bazeljavasdk_aspect' requested from @]//:bzljavasdk_aspect.bzl: The repository '@[unknown repo 'bazeljavasdk_aspect' requested from @]' could not be resolved: No repository visible as '@bazeljavasdk_aspect' from main repository. HOT 4
- Wrong Source Folder (despite src/main/java) HOT 3
- Classpath containers empty in Bazel 6.0 HOT 1
- Missing support for Auto Value Annotation Processor
- java.io.ioexception cannot run c:\msys64\usr\bin create process error 5 access denied HOT 1
- Bazel could not find information about selected project HOT 1
- Importing Gerrit bazel workspace fails with IllegalThreadStateException HOT 8
- Missing support for java_test in project-per-target provisioning strategy HOT 4
- `bazel` binary detection (in VSC with `bazel-vscode-java`) does not find custom script on `PATH` which runs `bazelisk` instead of `bazel` HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bazel-eclipse.