Allow JBR runtime package of distributions to be used--instead of automatically downloading a random binary VM #1437
Comments
|
The same problem exists on NixOS. There may also be other reasons to change the JVM. For example, I noticed #1452 while looking through the issues. Since 1.13.3 or #473, it does also affect all The following seems to work as an updated workaround which also changes the JVM of the tests: // Override JVM of gradle-intellij-plugin with JVM at `jbr/bin/java`
tasks.withType<RunIdeBase> {
projectExecutable = jbrExecutable.toString()
}
pluginManager.withPlugin("org.jetbrains.intellij") {
// Uses `withPlugin` because the following code must run after the gradle-intellij-plugin got applied.
// We must also use `afterEvaluate`, as the gradle-intellij-plugin uses `afterEvaluate` as well.
// Otherwise, gradle-intellij-plugin would just overwrite our configuration.
afterEvaluate {
tasks.withType<Test> {
executable = jbrExecutable.toString()
}
}
}Note that the |
|
I just noticed that If I use the JBR from NixOS … tasks.withType<RunPluginVerifierTask> {
resolvedRuntimeDir = jbrHome
}I run into the following exception: I am not sure for what the IntelliJ Plugin Verifier needs the JBR, as itself is running on another JVM. Assuming the plugin verifier does not execute the given JBR, but only uses it to check whether classes and methods do exist, maybe we could just avoid the initial probe by the |
|
In the 2.0 release, I've redesigned how the JBR is resolved and how you can configure it for your project. |
|
@hsz I actually tried 2.0 already and my solution got a bit simpler. NixOS/nix-idea@c912d4f#diff-13ca58d2e28bbe0bf7c4514d75a7ad23898fcf4ae547b4ecbb61ab5e90532fc0 If I remember correctly also |
|
The Is this solution involving BTW, you can also try: |
|
Ok, I went an extra mile here. ;) The path provided to Thanks to that, also The Related commit: 3e4277d |
I'm using IntelliJ IDEA in the GNU Guix Linux distribution.
Guix has a somewhat unusual filesystem setup. Among other things you won't be able to run a random foreign ELF executable because the loader is god knows where (specific example
/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2). That's because it's taking modularity seriously and so there is no "the"ld.so, there are many (on my dev system right now there are 32 different ones at the same time). There's no/libin the root directory at all.In order to make IntelliJ IDEA work nicely, we packaged jbr17, building it from https://github.com/JetBrains/JetBrainsRuntime/ like any other JDK is built. That made IntelliJ IDEA work nicely.
Eventually I got into IntelliJ plugin development. That is where the problems started.
The IntelliJ plugin, understandably, tries to use the JBR runtime in
RunIdeBase, and by inheritance also inBuildSearchableOptionsTask,RunIdeTask,RunIdeForUiTestTask,RunIdePerformanceTestTask,RunIdePerformanceTestTask. It makes sense to use the same JVM that is used for running the IDE also when testing the IDE, so that goal is fine.But none of them work because gradle-intellij-plugin downloads a binary JBR and then runs that, which won't work because it won't find
ld.so.I propose (and have successfully tested) to make gradle-intellij-plugin also heed a JBR VM specified via
gradle.propertieslike this:To be clear, why this is so difficult:
buildSearchableOptions,runIdeetc. It's NOT using the exact same one as in 1.It would be nice to enable 3. to use the exact same executables as 1. did.
The text was updated successfully, but these errors were encountered: