search

MinecraftForge / ForgeGradle

Minecraft mod development framework used by Forge and FML for the gradle build system
GNU Lesser General Public License v2.1
526 stars 447 forks source link

[5.x] Fix incompatibility with IntelliJ IDEA 2022.1 #847

Closed SizableShrimp closed 2 years ago

SizableShrimp commented 2 years ago

ForgeGradle depends on net.mcf:artifactural version 3.0.8, which depends on net.mcf:unsafe version 0.2.0, which depends on org.apache.logging.log4j:log4j-api:2.11.+ and org.apache.logging.log4j:log4j-core:2.11.+. These dynamic versions do not play nice with IntelliJ 2022.1. Due to them being dynamic, (I assume) Gradle queries the maven metadata for log4j on every gradle invocation. However, IntelliJ 2022.1 has a new feature to show progress of downloads, which requires knowing the content length of the file. Gradle, normally provides this value through the ProgressListener tooling API. However, for HTTP requests without a Content-Length header in the response, it uses a default of -1. IntelliJ throws a fit when it encounters this content length, and throws a (very unhelpful) exception of Invalid value: -1, no stacktrace. On both Forge's maven and Gradle's plugin repo, neither report the Content-Length header back in the response. Testing with Maven Central, it does seem to report this data. All declared buildscript repos will be searched for maven metadatas for log4j, since it is resolved on the Gradle plugin level. Because it is a requirement to get ForgeGradle through the Forge maven, there is no way to avoid this "invalid" lookup.

So basically, Gradle is stupid. And so is IntelliJ. Who would've thought! We can avoid this whole issue by just not allowing log4j api & core to be dynamically resolved. So, that's what is done by this PR. Stupid simple fix, and stupid problem.

canitzp commented 2 years ago

Good to finally know the issue. I for myself had to set gradle to version 7.3, so this doesn't happen with every task. Under 7.3 only the first task has this issue.

LexManos commented 2 years ago

This is not a fix, it is a hacky workaround for a gradle<->intellij incompatibility. As such, I will not pull this until the associated bugs are filed upstream and linked here so that we may keep track and know when to remove these hacks.

TheCurle commented 2 years ago

As requested, the IDEA issue is filed under https://youtrack.jetbrains.com/issue/IDEA-292250. Gradle issue is still being filed and will be edited here once it's submitted.

joelpelaez commented 2 years ago

I found a possible cause on the Gradle and Maven MinecraftForge Repo side.

When Gradle is trying to resolve dynamic dependencies it check the three repositories: custom server (MinecraftForge Repo), Maven Central y Gradle Plugin Server. The custom server has a Log4J "special" version: 2.11.2.lock, it has no artifacts and gradle request the maven-metadata.xml to resolve a compatible version.

If another minor version is requested, as 2.17+, the log4j maven-metadata.xml is not downloaded.

I attached the partial log related to dynamic resolutuon on version 2.11.+

PartialGradleLog.txt

LexManos commented 2 years ago

We've confirmed that it is a problem with gradle using -1 as the default if the OPTIONAL Content-Length header is not sent. And intellij just trusting that length. The Forge repo has nothing to do with it.