Add lsif-java command-line tool with Gradle and Maven support. #100
Conversation
Anonymous class symbols can't escape a single compilation unit so they can use local symbols according to the SemanticDB spec, and for consistency with the Scala implementation.
Previously, users needed to add manual configuration to their Gradle/Maven builds in order to use lsif-java. Now, users can run the new `lsif-java` command-line tool to automatically produce LSIF. In order to automatically produce LSIF, `lsif-java` needs to compile all the Java sources with an additional Java compiler options `-Xplugin:semanticdb`. Most build tools support a way to add custom compiler options but that typically requires updating build configuration files such as `pom.xml` for Maven and `build.gradle` for Gradle. However, we want to avoid updating build configuration files. The exact solution to update the compilation options varies between build tools: * Maven: you can customize the `javac` executable through the command-line flag `mvn -Dmaven.compiler.executable=PATH compile` * Gradle: you can pass in a custom Gradle script via `gradle --init-script=PATH`, which allows you to query information out of the build and configure settings. By default, `lsif-java` will try to configure the build to use a custom `javac` script similar to Maven. However, this approach does not work for Gradle builds that use the the newly released "Java toolchains" feature. For such builds, we can provide a custom `java` binary that registers a custom Java agent that ensures that Gradle always enabled the required `-Xplugin:semanticdb` flag.
README.md
Outdated
| | Java 12 | Untested, may work | | ||
| | Java 13 | Untested, may work | | ||
| | Java 14 | Untested, may work | | ||
| | Java 15 | Untested, may work | |
There was a problem hiding this comment.
Works on Java 15, just not formally in the CI test, so Im assuming youre leaving it out for that reason?
There was a problem hiding this comment.
Strictly speaking, the "Java 8" row should have the same message as Java 15. The next item on my agenda is to get cross-java CI working so this is only temporary.
| s"-Porg.gradle.java.installations.paths=${toolchains.paths()}", | ||
| s"--no-daemon" | ||
| ) | ||
| buildCommand ++= index.finalBuildCommand(List("clean", "compileTestJava")) |
There was a problem hiding this comment.
Curious what this is for, why compileTestJava is hardcoded
There was a problem hiding this comment.
Is there a better default command for gradle? I tried -x test build but it often skips compilation of test files and it also triggers integration tests. The user can override this command like this
lsif-java -- my custom gradle command
There was a problem hiding this comment.
Ah okay didn't know its overridable, seems fine then 🙂 Ive a feeling some of the android projects arent emitting semanticdb files due to using different compile task names, but Im not sure, would've thought build would catch it
There was a problem hiding this comment.
The injected gradle settings specifically target the java plugin, which isn't used in android projects. I saw that the errorprone plugin had android specific logic, which we may need to learn from
This makes it easy to open the workspace in Ubuntu to reproduce CI issues locally.
The `lsif-semanticdb` binary was not available on PATH.
olafurpg
force-pushed
the
build-tools
branch
3 times, most recently
from
0bce763 to
117ebbf
Compare
Previously, the build used the Java version that `sbt` was launched with. Now, the build automatically downloads appropriate Java versions for each project. * Build by default with Java 11. * Build compiler plugin with Java 8. * Cross-build the "minimized" project for Java 8/11/15.
| import java.nio.file.Paths; | ||
| import java.util.List; | ||
|
|
||
| public class InjectSemanticdbOptions { |
There was a problem hiding this comment.
Just for the sake of someone coming to read this in the future, it mightnt be a bad idea to briefly explain how this works. Its a fairly dense function 😄
There was a problem hiding this comment.
Good catch! This is the hairiest part of the PR and it was definitely missing documentation. I was considering writing this logic in a bash script originally, but figured it would be easier to maintain as a small Java program.
Previously, users needed to add manual configuration to their
Gradle/Maven builds in order to use lsif-java. Now, users can run the
new
lsif-javacommand-line tool to automatically produce LSIF.In order to automatically produce LSIF,
lsif-javaneeds to compile allthe Java sources with an additional Java compiler options
-Xplugin:semanticdb. Most build tools support a way to add customcompiler options but that typically requires updating build
configuration files such as
pom.xmlfor Maven andbuild.gradleforGradle. However, we want to avoid updating build configuration files.
The exact solution to update the compilation options varies between
build tools:
javacexecutable through thecommand-line flag
mvn -Dmaven.compiler.executable=PATH compilegradle --init-script=PATH, which allows you to query information outof the build and configure settings. By default,
lsif-javawill tryto configure the build to use a custom
javacscript similar toMaven. However, this approach does not work for Gradle builds that use
the the newly released "Java toolchains" feature. For such builds, we
can provide a custom
javabinary that registers a custom Java agentthat ensures that Gradle always enabled the required
-Xplugin:semanticdbflag.Fixes #87
Fixes #56