Multiple source sets not supported by annotation processor

[kr1viah]

Currently, when using multiple source sets, the annotation processor doesn't combine the created maps, thus making the developer choose what source set should be used by MaLiLib API. Ideally it would combine the created maps

[CodeWithCharles]

Ran into this on redstonetools today, with a couple of extra data points.

The two indexes are fully disjoint for us: 55KB of common classes, 77KB of client classes, no shared keys. So in practice it isn't the developer choosing a source set, nothing surfaces the choice at all. Loom <=1.16 silently keeps one and drops the other. Our shipped 1.21.x jars only contain the client index and nobody noticed.

It's also, sadly, a hard failure now rather than just data loss. Loom 1.17 refuses to write a zip with duplicate entries, giving that error :

  java.util.zip.ZipException: duplicate entry: META-INF/kr1v/index.json
    at net.fabricmc.loom.util.ZipReprocessorUtil.copyZipEntry
    at net.fabricmc.loom.task.ManifestModificationAction.modifyManifest

Since 26.2 needs Loom 1.17, this blocks porting instead of quietly degrading.
One thought on "ideally it would combine the created maps": I'm not sure the processor can. main and client are separate javac invocations with separate output dirs, and the client round can't see main's output. So the combine probably has to happen at packaging time, or the runtime has to load several indexes under distinct names.

---

Discord : kiwicometaire