Instead of using jbrVersion to use a JBR variant I propose a jbrVariant
#852
Comments
hsz
added a commit
that referenced
this issue
Feb 7, 2022
…`runIde`, `runPluginVerifier`, `buildSearchableOptions`, and `runIdeForUiTest` tasks #852
|
@bric3 Thanks for the suggestion – it's now implemented and will be available with the following |
Salomon88
pushed a commit
to Salomon88/gradle-intellij-plugin
that referenced
this issue
Feb 18, 2022
…`runIde`, `runPluginVerifier`, `buildSearchableOptions`, and `runIdeForUiTest` tasks JetBrains#852
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since 1.3.0 we can use multiple variant of the JBR, see #818. However the current approach allow this by specifying the whole version.
This approach has some drawback as it requires plugin developers to make sure the JBR is compatible with the base IntelliJ version, point in case :
If I want to use the latest Java 11 with DCEVM I will likely enter this version
jbr_dcevm-11_0_13b1751.19, however IntelliJ 2021.1 isn't compatible with this JBR (there's no access to application Preferences). For IntelliJ 2021.1.3 you need to usejbr_dcevm-11_0_11b1341.60.This makes the whole development brittle as this require to constantly check the JBR version matches with current IntelliJ version.
I believe a simpler approach for us to consume is to be able to indicate the runtime variant (
dcevm,fastdebug, etc), and let gradle-intellij-plugin find the correct runtime version.The text was updated successfully, but these errors were encountered: