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
Fixes the issue described in #108, currently POC status.
Problem: When using delegated Gradle actions, IntelliJ creates a
GradleRunConfiguration
out of theApplicationConfiguration
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 theIdeaRunConfigurationExtension
receives theGradleRunConfiguration
, it will not find any config in theGradleRunConfiguration
s user data. Instead, this PR introduces a hook into theGradleRunConfiguration
creation process. After the config is created, it reads the originalApplicationConfiguration
s userData and applies the standard envFile process.There's a few aspects I'm not satisfied with:
executionEnvironmentProvider
extension point is defined withorder="first"
- this is because theGradleProjectTaskRunner
uses the first provider it encounters. Usually this will be aGradleApplicationEnvironmentProvider
. We then use the next-best provider as a delegate for theGradleRunConfiguration
creation. This whole behavior aroundexecutionEnvironmentProvider
is 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