search

neoforged / NeoGradle

Gradle plugin for NeoForge development
GNU Lesser General Public License v2.1
44 stars 24 forks source link

JarJar does not work with certain libraries #222

Closed thedarkcolour closed 2 months ago

thedarkcolour commented 3 months ago

I was having an issue with one of my mods that jarjars Kotlin Serialization and noticed it was missing from the final JAR. image

I tried to reproduce this in a barebones workspace, and Serialization didn't show up in the fatjar either. Here's the test repo: 1.21 KotlinForForge template

Adding the same buildscript code as in that test repo with a ForgeGradle workspace works just fine.

lukebemish commented 2 months ago

Off the top of my head this could be due to kotlinx-serialization publishing its standard JVM artifacts via an available-at directive in the module info (see https://repo1.maven.org/maven2/org/jetbrains/kotlinx/kotlinx-serialization-json/1.7.1/kotlinx-serialization-json-1.7.1.module) which -- given the issue you're seeing here -- it seems gradle treats as a transitive dep, or perhaps just has issues figuring out group/artifact name data about. I'll try to poke it a bit more and see if I can diagnose the exact issue.

lukebemish commented 2 months ago

Figured out the issue; due to the available-at directive, the artifact to include has the ID org.jetbrains.kotlinx:kotlinx-serialization-json-jvm:1.7.1 while the resolved component attached to it has the ID org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.1. Solving this sensibly will be... hard, but doable in theory. Gotta see if there's any way to recover the requested component ID from the artifact.

thedarkcolour commented 2 months ago

I'm just using ForgeGradle for now. It works fine on there, you might be able to track down where the bug was introduced

lukebemish commented 2 months ago

ForgeGradle still uses the old jarJar implementation, which is... Atrocious, and does a lot of gradle bad practice (and hence has its own set of bugs -- see, including jars it doesn't list in the metadata and stuff like that). This bug was introduced in my complete rewrite of the gradle side of jarJar and is a consequence of an edge case I hadn't considered when implementing everything the right way. I poked it yesterday and I should have a solution -- the module ID of where the contained stuff is available-at is available through the variant list of the root component, so I should be able to recover what's needed there. I'll hopefully PR a fix in the next few days.