A Maven goal or Gradle task run from the build tool window carried the JAVA_HOME the build model had when the tree was built, and that value was frozen into the (persisted) temporary configuration, so correcting the JDK in Settings only took effect after a restart, or not at all. For IDE-generated build-tool configurations JAVA_HOME is now derived: Settings (the Maven runner JRE, the Gradle JVM) decide at each launch, a saved configuration drops the derived value, and a dead path no longer outlives its setting. Configurations of the user's own, and Tomcat's JDK field, keep their JAVA_HOME.
Fixes#2433
Co-authored-by: ppxb <17081240+ppxb@users.noreply.github.com>
Opening a folder of independent Gradle builds selected only the first build. Link Gradle Projects… (pick a build's settings or build file) and Unlink on a build's root let an ordinary project window manage several independent builds without changing their scripts. The build model holds a list of Gradle builds; each keeps its own wrapper, working directory, environment, task routing and sync cache, keyed by the owning build directory. The links persist in the project's Gradle settings (linkedProjects); unlinking leaves files and saved run configurations alone. Existing includeBuild support is unchanged, and an explicitly linked build takes precedence over a composite that also includes it. Workspace windows keep Link/Unlink disabled.
Co-authored-by: gudcks0305 <84506708+gudcks0305@users.noreply.github.com>
ppxbandppxb
yoo hyeong chan