How to Trigger Dynamic Plugin Reload
Answered
So I understand that there is some configuration to do to Enable Dynamic Plugin Reloading, however I'm not clear about exactly how to actually trigger this. Using the IntelliJ Platform Plugin Template Project, which uses the IntelliJ Gradle Plugin. I don't see what step 2 is below
1. Make code change
2. ???
3. IDE reloads
Even if I run something like `./gradlew -t jar` which continuously builds the jar, that jar is going to /build/libs and not /builds/idea-sandbox/plugins/<pluginName>/lib which is where it needs to go. I have manually created a copy task, but this seems hacky and annoying. Using `prepareSandbox` seems terrible since _every_ plugin gets reloaded.
Please sign in to leave a comment.
One should use "buildPlugin" Gradle task that copies the plugin to the sandbox. Only plugins located in sandbox/plugins get reloaded automatically in the debug IDE instance.
I can't test at the moment, but are you sure about that answer. There are a few things I see as problematic with it:
1) When I run buildPlugin it does not seem to update the copy of the plugin in the sandbox directory.
2) When I run buildPlugin it runs buildSearchableOptions which I think crashes and fails if you are running the sandbox IDE.
1) it should. please make sure you're using the latest version (v0.6.5) or post your plugin to reproduce
2) that can be disabled easily https://github.com/JetBrains/gradle-intellij-plugin/blob/master/FAQ.md#how-to-disable-building-searchable-options
Yann Cebron I'm running into the same issue. How is the dynamic plugin reloading suppose to work in a development workflow?
My code at the moment gets HotSwapped when I change method bodies. But when I change the `plugin.xml` file or something else, I would expect the plugin to be reloaded without having to re-run the IDE.
Vaughan Rouesnel FYI here is the code I use:
tasks.register<Copy>("copy_jar") {val sourceFile: File = tasks.getByName<Jar>("jar").archivePath
from(sourceFile)
into(tasks.getByName<org.jetbrains.intellij.tasks.RunIdeTask>("runIde").pluginsDirectory.absolutePath + "/$pluginName_/lib/")
}
Then just open a new terminal and run:
You have to switch focus between the IDE and sandbox but it works fairly reliably. I also filed a few bugs as reloading only works when:
1) You aren't running in debug mode.
2) The UI of the plugin doesn't have focus.
This is basically doing what I recommended previously
> One should use "buildPlugin" Gradle task that copies the plugin to the sandbox.
The debug instance does monitor the .jar file and triggers reload. Like this, also changes in plugin.xml will trigger reload.
So I tried again with a simple no-op plugin, and yes, disabling search options, and then using buildPlugin does seem to work.
If runIde is started in DEBUG mode it however doesn't work. To be clear, it detects the changes and tries to do it, but the reload always fails on debug, even in a simple project.
Steve R Yes, this is indeed expected, see https://youtrack.jetbrains.com/issue/IDEA-259005#focus=Comments-27-4624327.0-0. We'll clarify the SDK Docs, thanks for noticing.
I run runIde again and it triggers auto reloading.
Yann Cebron Can you add to the docs that you must run the `buildPlugin` task. https://plugins.jetbrains.com/docs/intellij/ide-development-instance.html#enabling-auto-reload
Or better yet, add a `Build for reload` Run Configuration that ships with the template.
I think most people would expect `Build project` action to trigger a reload, and then are surprised when it doesn't work.
Above page already has requested change since August?
> After starting the sandbox IDE instance, run `buildPlugin` task after modifications in the plugin project and switch focus back to sandbox instance to trigger reload.