You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a use case where we use a different compile time jdk than the runtime jdk. For example, I would like to compile sources with the jdk8, but when running the classes with a junit test runner, I want to use jdk11.
The context in which I'm operating is by using bloop which does seem to have enough code context to have completely different configuration sets for java home and flags. When using a bsp plugin for intellij, there doesn't seem to be a way via the protocol to support different jdk compile vs runtime.
JvmBuildTarget is where a jvm project home would be located, when a test target is triggered the JvmEnvironmentItem will be queried for, and this includes the jvmOptions. In the situation where the bsp project has materialized the misc.xml to have <component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" project-jdk-name="BSP_8" project-jdk-type="JavaSDK" /> at the time of test, bloop would have configured a runtimeConfig of jdk11, flags and all, the bloop server would get a query for JvmEnvironmentItem that would return the flags for jdk 11.
What I think is unclear is if there is a difference with intellij to setup projects to build with one jdk, but run/execute on a different one. If that is not supported by intellij, then that mostly answer the question. Alternative is how could bsp specification and integration with intellij support such use case?
I've recently started working a bit between these software stacks for some internal plugins/code, please excuse any ignorance in communication about it.
What do you propose
No response
I've checked to make sure there isn't already a way to support this in the current protocol
I've checked the existing protocol and there isn't a way to do this currently
Maintainer approval (This is for the maintainers)
Jetbrains
Metals
Scala Center
The text was updated successfully, but these errors were encountered:
@tgodzik setting the home upon launching the test is something intellij can support? Thats where I think things broke down, wasn't sure if intellij provides the ability to use different jdk for compile and run
@tgodzik setting the home upon launching the test is something intellij can support? Thats where I think things broke down, wasn't sure if intellij provides the ability to use different jdk for compile and run
Probably best to ask someone from Jetbrains, I am not sure.
Describe the use-case for this feature
I have a use case where we use a different compile time jdk than the runtime jdk. For example, I would like to compile sources with the jdk8, but when running the classes with a junit test runner, I want to use jdk11.
The context in which I'm operating is by using bloop which does seem to have enough code context to have completely different configuration sets for java home and flags. When using a bsp plugin for intellij, there doesn't seem to be a way via the protocol to support different jdk compile vs runtime.
https://build-server-protocol.github.io/docs/extensions/jvm/ defines two things that seem to lead to this incompatibility (and it might be an inherent limitation with intellij generally speakling, opening issue to learn or understand more)
JvmBuildTarget
is where a jvm project home would be located, when a test target is triggered theJvmEnvironmentItem
will be queried for, and this includes thejvmOptions
. In the situation where the bsp project has materialized themisc.xml
to have<component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" project-jdk-name="BSP_8" project-jdk-type="JavaSDK" />
at the time of test, bloop would have configured aruntimeConfig
of jdk11, flags and all, the bloop server would get a query forJvmEnvironmentItem
that would return the flags for jdk 11.What I think is unclear is if there is a difference with intellij to setup projects to build with one jdk, but run/execute on a different one. If that is not supported by intellij, then that mostly answer the question. Alternative is how could bsp specification and integration with intellij support such use case?
I've recently started working a bit between these software stacks for some internal plugins/code, please excuse any ignorance in communication about it.
What do you propose
No response
I've checked to make sure there isn't already a way to support this in the current protocol
Maintainer approval (This is for the maintainers)
The text was updated successfully, but these errors were encountered: