It's counterintuitive but modRuntimeOnly dependencies still get forwarded into your Maven POM. Since nmuk declares a modRuntimeOnly dep on LazyDFU,

this means anyone depending on nmuk, or a mod that depends on it (like amecs-api), will be required to pull in that dependency too. This means a wild goose chase to figure out which Maven server it's hosted on, etc.

You can see that the POM for 1.0.1-mc1.18-pre1 includes this at the bottom: https://maven.siphalor.de/de/siphalor/nmuk-1.18/1.0.1%2Bmc1.18-pre1/nmuk-1.18-1.0.1%2Bmc1.18-pre1.pom

    <dependency>
      <groupId>com.github.astei</groupId>
      <artifactId>lazydfu</artifactId>
      <version>master-SNAPSHOT</version>
      <scope>runtime</scope>
    </dependency>

This probably isn't what you wanted to do. Recentish versions of Loom provide modLocalRuntime which does what you'd expect (just brings the mod into your personal dev workspace)

Btw, while I'm busy poking at your build.gradle:

You might enjoy that Loom has some special syntax for "depend on just one module from a given fabric-api release":

modImplementation fabricApi.module("fabric-key-binding-api-v1", project.fabric_api_version)
modLocalRuntime fabricApi.module("fabric-resource-loader-v0", project.fabric_api_version)

This should make it easier to update things, you can simply manage a fabric_api_version variable like you do on any other project but Loom will only download the requested modules out of fabric-api. Kinda neat. Thanks for depending on the minimal set of fabric-api modules btw, love when people do that aha

This issue has been marked as stale because of inactivity. Comment on this issue or it will be closed in 14 days.

Oh, nice.

I completely forgot about this issue ^^

Yeah, both of these features didn't exist when I created the mod.
I'm gonna fix it now, but the POM changes will of course only be propagated on the next release.

Thanks for submitting this and the detailed explanations :)