Model runtime dependencies in JDT
plaird opened this issue · 2 comments
The initial problem report was incorrect. But the discussion further down explores the issue.
In our internal monorepo, we explicitly manage and list the transitives of external deps. We don't allow maven_install to compute transitives for us. However, most users will rely on maven_install for this, and this appears to be broken.
Reproducer:
import this workspace: https://github.com/salesforce/bazel-demo/tree/main/main_usecases/java/simplejava-mvninstallnotice the apple-api package it depends on spring-coresee that spring-core depends on spring-jcl pom.xmlnotice that the Bazel classpath container for that package only has spring-core, it did not transitively add spring-jcl
After thinking about this, I don't remember if this was intentional but I actually think the existing behavior is correct. We just need better docs for it. Bazel is more sophisticated than Eclipse JDT when it comes to classpath. Not only can Bazel have a different classpath per target (see #407) but Bazel also differentiates between compile and runtime classpaths.
The essence of this issue is that transitives are runtime classpath entries, and are not available at compile time. JDT only has the main classpath, so the real question is how best to model Bazel in JDT. There are two options:
- JDT main classpath = Bazel compile + runtime deps
- JDT main classpath = Bazel compile deps
It is actually more correct to do the second, because code completion should not allow a user to make a reference to a runtime dep. That will break the Bazel build. The user must first promote the dep from runtime to compile dep in order to use it in an import statement. So we will retain the existing behavior (second option above).
It is important to know the our Bazel launcher already builds the full (compile+runtime) classpath when launching an app or running tests.
New DoD:
- explore how JDT handles Maven provided and runtime scopes
- create a graphic in LucidChart that shows how Bazel classpath in a package maps into JDT.
- update the classpath doc with this information, plus the recent discussion about why we don't do target scoped classpaths today (#407)
- create a JUnit test to make sure transitives do not appear on JDT main classpath