Fixes the issue described in #108, currently POC status.
Problem:
When using delegated Gradle actions, IntelliJ creates a GradleRunConfiguration out of the ApplicationConfiguration and sets variables like env vars, VM params etc. What it doesn't set is UserData, which is the mechanism EnvFile uses to persist the list of env files per config. Therefore, when the IdeaRunConfigurationExtension receives the GradleRunConfiguration, it will not find any config in the GradleRunConfigurations user data.
Instead, this PR introduces a hook into the GradleRunConfiguration creation process. After the config is created, it reads the original ApplicationConfigurations userData and applies the standard envFile process.
There's a few aspects I'm not satisfied with:
The executionEnvironmentProvider extension point is defined with order="first" - this is because the GradleProjectTaskRunner uses the first provider it encounters. Usually this will be a GradleApplicationEnvironmentProvider. We then use the next-best provider as a delegate for the GradleRunConfiguration creation. This whole behavior around executionEnvironmentProvider is a bit too undocumented imo
ashald
commented
4 years ago
Fixes the issue described in #108, currently POC status.
Problem: When using delegated Gradle actions, IntelliJ creates a
GradleRunConfigurationout of theApplicationConfigurationand sets variables like env vars, VM params etc. What it doesn't set is UserData, which is the mechanism EnvFile uses to persist the list of env files per config. Therefore, when theIdeaRunConfigurationExtensionreceives theGradleRunConfiguration, it will not find any config in theGradleRunConfigurations user data. Instead, this PR introduces a hook into theGradleRunConfigurationcreation process. After the config is created, it reads the originalApplicationConfigurations userData and applies the standard envFile process.There's a few aspects I'm not satisfied with:
executionEnvironmentProviderextension point is defined withorder="first"- this is because theGradleProjectTaskRunneruses the first provider it encounters. Usually this will be aGradleApplicationEnvironmentProvider. We then use the next-best provider as a delegate for theGradleRunConfigurationcreation. This whole behavior aroundexecutionEnvironmentProvideris a bit too undocumented imocom.intellij.gradle, which was introduced in https://github.com/JetBrains/intellij-community/commit/85c68dc7f1e58fab60ffd5d958c12176559245a8 IDEs released without this commit will still encounter this bugAny input is welcome