intellij-platform-gradle-plugin
intellij-platform-gradle-plugin copied to clipboard
Cannot use EAP snapshots in 2.0.0-beta5
What happened?
Timeline for context
- My plugin failed compatibility verification for IntelliJ build
242.10180.25 - I got very confused, but eventually figured out that I need to migrate from "Gradle IntelliJ Plugin 1.14.1" to the "IntelliJ Platform Gradle Plugin".
- I started the migration with
2.0.0-beta4and then switched to2.0.0-beta5. - Eventually I managed to build my plugin against IntelliJ IDEA Community
2024.1.2.
Problem
I'm trying to ensure that my plugin will be compatible with IntelliJ 2024.2 (which hasn't been released yet), but using EAP builds with the new plugin (2.0.0-beta5) fails.
Relevant log output or stack trace
* What went wrong:
Could not determine the dependencies of task ':buildSearchableOptions'.
> Failed to query the value of task ':buildSearchableOptions' property 'runtimeDirectory'.
> No IntelliJ Platform dependency found.
Please ensure there is a single IntelliJ Platform dependency defined in your project and that the necessary repositories, where it can be located, are added.
See: https://plugins.jetbrains.com/docs/intellij/tools-intellij-platform-gradle-plugin-dependencies-extension.html
Steps to reproduce
-
Specify
242.12881.66-EAP-SNAPSHOT(built on2024-05-29 06:22:58 UTC, see snapshot repository), as a platform dependency in the Gradle build script:repositories { mavenCentral() intellijPlatform { defaultRepositories() } } dependencies { intellijPlatform { create("IC", "242.12881.66-EAP-SNAPSHOT") ... } } -
Run
./gradlew --refresh-dependencies clean buildPlugin
Gradle IntelliJ Plugin version
2.0.0-beta5
Gradle version
8.7
Operating System
Linux
Link to build, i.e. failing GitHub Action job
No response
FWIW, you can check my PRs https://github.com/VirtusLab/git-machete-intellij-plugin/pull/1846, https://github.com/VirtusLab/git-machete-intellij-plugin/pull/1859. Still, I haven't got verifyPlugin to work as it did in 1.x yet (https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1637).
In the changelog of beta2, it was noted that we're switching to CDN as a primary source of IntelliJ Platform archives. To switch back to IJ Maven repository, use the following Gradle property:
org.jetbrains.intellij.platform.buildFeature.useBinaryReleases=false
This mechanism is still under development and looking at the feedback, I have to make more transparent.
Thank you! Adding the property to the command:
$ ./gradlew -Porg.jetbrains.intellij.platform.buildFeature.useBinaryReleases=false buildPlugin
fixes the build for me!
I tried the option org.jetbrains.intellij.platform.buildFeature.useBinaryReleases to get the EAP working, but once I do that, the plugin doesn't use the JetBrains runtime any more when running ./gradlew clean runIde
Instead, it starts the IDE with the JDK I'm using to build the plugin. Due to that, JCEF isn't present, which I need for my developing parts of my plugin.
Reproducible in the template project on the 2.0.0 branch which is currently on 2.0.0-beta5 by running
./gradlew -Porg.jetbrains.intellij.platform.buildFeature.useBinaryReleases=false clean runIde
Is there a way to use the EAP build with the JBR and JCEF?
You need to add a dependency on JCEF explicitly.
dependencies {
intellijPlatform {
...
jetbrainsRuntime()
}
}
Thank you @hsz for the answer. After adding it also to the repository, it now works for me as expected. With the keyword from your answer I also found the matching docs page.
I'm still a little surprised I need to specify JBR manually instead of using it manually, as I wouldn't know which other runtime I would use as a plugin developer when running a plugin.
Apparently the useBinaryReleases doesn't work anymore with 2.0.0-beta9. Still, EAP releases don't work with the plugin, see the following comment for a workaround:
https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1693#issuecomment-2225786901
EAP releases don't work with the plugin, see the following comment for a workaround
Nitpicking: EAP releases work but are officially no longer a primary source of IntelliJ Platform. To switch from installers to IJ Maven repository, you need to:
dependencies {
intellijPlatform {
intellijIdeaCommunity("242-EAP-SNAPSHOT", useInstaller = false)
}
}
This is not a workaround. ;-)
Note that installers contain JBR bundled. When switching off, you have to provide JBR to IntelliJ Platform to make it working properly. To do so, use the above jetbrainsRuntime() dependency helper along with required repository:
repositories {
intellijPlatform {
defaultRepositories()
jetbrainsRuntime()
}
}
dependencies {
intellijPlatform {
intellijIdeaCommunity("242-EAP-SNAPSHOT", useInstaller = false)
jetbrainsRuntime()
}
}
EAP releases work but are officially no longer a primary source of IntelliJ Platform.
3rd party plugin developers like me are supposed to test our plugins against EAP to have plugin releases available once they [IntelliJ releases] are officially released.
This distinction and extra configuration makes it more difficult for me (and I suppose other as well), so it leaves me in an annoyed state as it is diverting my efforts to accidental complexity and technical details.
cc: @YannCebron
For a long time, I've heard that the old dependencies and repositories management is broken.
1.x was adding custom repositories and dependencies on various libraries, JBR, etc without your knowledge, which was hard to maintain in terms of proxifying artifacts, offline work, security, defining repositories in settings instead of project-level configuration, etc. I've fixed that. "Unfortunately", now you have control over that and to get things working, you apply defaultRepositories() or a single IntelliJ Platform dependency and get this working.
If you plan to use non-default EAP releases, it's good if you understand what you're doing.
I've elevated everything to make you change one switch and a missing JBR which is an effect of using IntelliJ Platform artifacts that don't have it bundled.
it leaves me in an annoyed state as it is diverting my efforts to accidental complexity and technical details
I'm sorry, but comparing this against closing 95 issues so far, where most of them were not even remotely possible to address in 1.x is a fair deal. I don't think the above snippet, which makes it possible to work with EAP (EAP is not GA!), is complex, and for sure not accidental.
@hsz - thank you for the work you are putting into this plugin, and thank you for making EAP work. I hope this will find its way into he docs.
Let's agree that we then disagree about the "accidental complexity" bit.
It also seems that I'm missing how 3rd party developers should test EAP releases given your statement below:
If you plan to use non-default EAP releases, it's good if you understand what you're doing.
Can you please elaborate how and if you expect 3rd plugin developers to test EAP releases?
I may be wrong, but we can easily test with EAP Snapshots. It requires some custom code, but you can find the version string from https://www.jetbrains.com/updates/updates.xml.
I did this with plugin v1, and now with v2 as I'm not a big fan of how versions are managed in v2 (things are less easy, and they require more boilerplate code, which is like a regression for me, but we already discussed that). My custom code: https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1628#issuecomment-2349436009