IntelliJ run configurations do not generate when Gradle is ran in an external process.

Ampflower commented 1 year ago

Expected Results:

On import, for Minecraft Server and Minecraft Client to be automatically populated for you by default.

Actual Results:

It seems that it's never being added.

Extra information:

Fabric Loom 1.0.17, 1.1.2, 1.1.3 (All failed to generate the profile)
Gradle 7.6
Semeru 17.0.2; GraalVM CE 22.0.2 - JDK 17.0.4

It's possible that a couple registry edits to IntelliJ might have broken it, will test again later.

IntelliJ IDEA

``` IntelliJ IDEA 2022.2.2 (Community Edition) Build #IC-222.4167.29, built on September 13, 2022 Runtime version: 17.0.4+7-b469.53 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Linux 6.1.1-arch1-1 GC: G1 Young Generation, G1 Old Generation Memory: 4096M Cores: 20 Registry: gradle.tooling.use.external.process=true gradle.version.catalogs.dynamic.support=true gradle.improved.hotswap.detection=true gradle.settings.showDeprecatedSettings=true Non-Bundled Plugins: org.ziglang.jb (0.1.0) org.rust.lang (0.4.178.4873-222) net.seesharpsoft.intellij.plugins.csv (2.19.0) name.kropp.intellij.makefile (222.4167.21) idea.plugin.protoeditor (222.4167.21) com.jetbrains.plugins.ini4idea (222.4167.25) com.intellij.plugins.watcher (222.4167.21) com.intellij.grazie.pro (0.3.110-221-222) ru.artyushov (1.3.0) org.jetbrains.kotlin (222-1.8.0-release-345-IJ4167.29) nim.lang (0.0.0.6) net.earthcomputer.quiltflowerintellij (1.0.3) net.earthcomputer.classfileindexer (1.1.3) com.intellij.java.rareRefactorings (222.4167.21) com.github.tth05.minecraft-nbt-intellij-plugin (1.5.3) gherkin (222.4167.21) cucumber-java (222.4167.21) PythonCore (222.4167.29) org.exbin.deltahex.intellij (0.2.6) Docker (222.4167.25) Dart (222.4167.21) DBN (3.3.2160.0) CheckStyle-IDEA (5.70.0) org.intellij.scala (2022.2.13) izhangzhihao.rainbow.brackets (6.26) com.demonwav.minecraft-dev (2022.2-1.5.21) Kotlin: 222-1.8.0-release-345-IJ4167.29 Current Desktop: KDE ```

modmuss50 commented 1 year ago

Is this with the eample mod? We havent made any changes to 1.0 recently that would cause this.

Ampflower commented 1 year ago

Yes, example mod alone was enough; I could try binary searching which Loom introduced the bug and see.

modmuss50 commented 1 year ago

I highly doubt this is a loom bug, as these loom versions have been used for a long time without anyone else having issues. It is working as expected for me.

Ampflower commented 1 year ago

0.9.54 with 1.18.2 generated the files. 1.0.1 also with 1.18.2 failed to generate the files.

I can poke at the registry settings in IntelliJ and see if they're interfering at all with 1.+.

Do you by chance know of any Loom-specific debug flags I could potentially throw in to see why it is or isn't generating the run configs, if the registry options don't do anything?

modmuss50 commented 1 year ago

Check the run configs are in .idea/runConfigurations
If this is a sub project the run configs do not generate by default
Check that the idea sync task is running when you refresh gradle
Sometimes idea needs to be reopened to detect the new run configs

I dont know what you mean by registry settings, the windows registry? If so we dont have anything to do with that.

Ampflower commented 1 year ago

Looks like it was a bug with gradle.tooling.use.external.process=true that somehow interfered with how 1.0.1+ added run configurations. Resetting it back to false allows Loom to generate the IDE configuration correctly, which IntelliJ does see nearly immediately.

Might be an environment change compared to just running in the IDE, maybe? Tho, I'd expect the behaviour to be consistent regardless of how it's running during sync.

I dont know what you mean by registry settings, the windows registry? If so we dont have anything to do with that.

IntelliJ has its own registry full of various variables that can change how the IDE does things.

Tho, given that the bug was caused by bad user configuration than Loom itself, unless you want to support the odd use case in case JetBrains makes it a new default (potentially seeing why it works with 0.9 but not 1.0), might be good to close this?

modmuss50 commented 1 year ago

gradle.tooling.use.external.process I dont see any documentation on this, beyond Enable running gradle tooling api out of IDE process in the source code.

I expect this is breaking the way loom detects the idea sync here; https://github.com/FabricMC/fabric-loom/blob/dev/1.1/src/main/java/net/fabricmc/loom/configuration/ide/idea/IdeaUtils.java#L34-L36 This may be an idea bug? Im not too sure

Ampflower commented 1 year ago

Tossing System.out.println(System.getProperty("idea.sync.active")) into the main build.gradle, it does seem to still pass that flag directly as it prints true.

Passing org.gradle.logging.level=debug via gradle.properties works for getting logs, tho, I don't know what to look for in there.

runConfiguration isn't mentioned in the log output in any capacity.

FabricMC / fabric-loom