Cannot use EAP snapshots in 2.0.0-beta5

[rybak]

What happened?

Timeline for context

1. My plugin failed compatibility verification for IntelliJ build 242.10180.25
2. 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".
3. I started the migration with 2.0.0-beta4 and then switched to 2.0.0-beta5.
4. 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

1. Specify 242.12881.66-EAP-SNAPSHOT (built on 2024-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")
   		...
   	}
   }
   

2. 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

[PawelLipski]

FWIW, you can check my PRs VirtusLab/git-machete-intellij-plugin#1846, VirtusLab/git-machete-intellij-plugin#1859. Still, I haven't got verifyPlugin to work as it did in 1.x yet (#1637).

[hsz]

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.

[rybak]

Thank you! Adding the property to the command:

$ ./gradlew -Porg.jetbrains.intellij.platform.buildFeature.useBinaryReleases=false buildPlugin

fixes the build for me!

[ahus1]

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?

[hsz]

You need to add a dependency on JCEF explicitly.

dependencies {
  intellijPlatform {
    ...
    jetbrainsRuntime()
  }
}

[ahus1]

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.

[ahus1]

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:

#1693 (comment)

[hsz]

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()
  }
}

[ahus1]

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

[hsz]

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.

[ahus1]

@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?