architectury / architectury-plugin

A simple gradle plugin to enable developing multiplatform mods.

Architectury Plugin

Talk to us on Discord!

Architectury Plugin is a gradle plugin to allow easier multi-modloader set-ups using a common module.

More documentation: Architectury Wiki

Example Mod

• Architectury Example Mod

Important Information

• Environment and EnvType are remapped to OnlyIn and Dist on forge.

Implementing Platform Specific APIs

Notes: Only works for static methods.

IntelliJ Plugin

https://plugins.jetbrains.com/plugin/16210-architectury

How does it work

Fabric Side:

• Module fabric depends on a transformed version of common, which is shaded afterwards
• A fake mod is generared, to let fabric load it on the correct class loader and let fabric load its assets

Forge Side:

• Module forge depends on a transformed version of common, which is shaded afterwards
• A fake mod is generated, to let forge load it on the correct class loader and let forge load its assets

Usage

Your gradle version MUST be equals or above 5.5.1, all assets or data should go into the common module, with modloader specific files to their corresponding modules.

architectury-plugin's Issues

[FEATURE REQUEST] Cross-platform merged jar (with relocated packages?)

like in https://github.com/shedaniel/LightOverlay/blob/b48c6001431dc385f7cb87a5ba6c7bd44cdf4434/build.gradle#L50-L182

Consistently getting an error that "transformDevelopmentFabric.jar" is locked.

Error looks like this and generally occurs when trying to build multiple times consecutively:

Execution failed for task ':common:transformDevelopmentFabric'.
> java.nio.file.FileSystemException: C:\Users\Admin\Documents\Code\Physics-AndShips\common\build\libs\valkyrienskies-116-1.0.0-transformDevelopmentFabric.jar: The process cannot access the file because it is being used by another process.

It's resolved by killing all the background java processes on my PC. (but not gradlew --stop, make what you will of that)

AddRefmapName doesn't consider client source set mixins in the refmap name

architectury-plugin/src/main/kotlin/dev/architectury/plugin/transformers/AddRefmapName.kt

Line 42 in 0a37a6b

val refmap = System.getProperty(BuiltinProperties.REFMAP_NAME)

This property is always the main refmap name, but it needs to be adjusted for client-only code.

Cannot run Forge 1.16.5 in dev env

I am currently trying to migrate a 1.16.5 mod to Architectury and for debugging, it would be very nice to be able to use the generated Architectury run configurations in IntelliJ.
However, as soon as the Minecraft client gets to the main menu, it crashes. Here is my log: https://paste.ee/p/BBmj0
I am unsure what the exact cause of this issue is - probably either something that went wrong during transformation (in this case: sorry - I will reopen this issue in the architectury-transformer repo) or something inside the architectury-plugin went wrong.
What I have tried so far: gradlew clean, gradlew --refresh-dependencies, invaliding caches in IntelliJ, completely deleting the .idea folder manually and reinitialising the project

Also, gradlew forge:runClient yields exactly the same error.
I should also mention: I only tried with the Minecraft Client (Forge) configuration yet - there are some issues I want to resolve first before even attempting to start Fabric

Edit: I am using Architectury Loom 1.6 - maybe this could also be part of the issue

@ExpectPlatform fails without architectury api

@ExpectPlatform fails without architectury api

The ExpectPlatform annotation fails to work with the following error:

java.lang.RuntimeException: Could not execute entrypoint stage 'main' due to errors, provided by 'examplemod'!
	at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointUtils.invoke0(EntrypointUtils.java:53)
	at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointUtils.invoke(EntrypointUtils.java:36)
	at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointClient.start(EntrypointClient.java:32)
	at net.minecraft.client.Minecraft.<init>(Minecraft.java:437)
	at net.minecraft.client.main.Main.main(Main.java:177)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at net.fabricmc.loader.game.MinecraftGameProvider.launch(MinecraftGameProvider.java:226)
	at net.fabricmc.loader.launch.knot.Knot.init(Knot.java:139)
	at net.fabricmc.loader.launch.knot.KnotClient.main(KnotClient.java:27)
	at net.fabricmc.devlaunchinjector.Main.main(Main.java:86)
Caused by: java.lang.BootstrapMethodError: bootstrap method initialization exception
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:194)
	at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:315)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:271)
	at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:261)
	at net.examplemod.ExampleExpectPlatform.getConfigDirectory(ExampleExpectPlatform.java)
	at net.examplemod.ExampleMod.init(ExampleMod.java:7)
	at net.examplemod.fabric.ExampleModFabric.onInitialize(ExampleModFabric.java:9)
	at net.fabricmc.loader.entrypoint.minecraft.hooks.EntrypointUtils.invoke0(EntrypointUtils.java:50)
	... 12 more
Caused by: java.lang.IllegalStateException: No detected mod loader!
	at architectury_inject_architecturyexamplemod_common_80e7ac06d9504ad5a0a5229042c19c45.PlatformMethods.getModLoader(PlatformMethods.java:56)
	at architectury_inject_architecturyexamplemod_common_80e7ac06d9504ad5a0a5229042c19c45.PlatformMethods.platform(PlatformMethods.java:14)
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:206)
	at java.base/java.lang.invoke.BootstrapMethodInvoker.invoke(BootstrapMethodInvoker.java:90)
	... 19 more

The key part is No detected mod loader! which can be found in PlatformMethods in architectury-plugin.

Steps to Reproduce

1. Download architectury-example-mod
2. Remove architectury api as a dependency in the forge, fabric, and common modules.
3. Remove all architectury api references from the code
4. Run and get that crash

Test repository

I made a repository that uses the architectury-example-mod and only removes the architectury api. It crashes.

That can be found here for your testing: https://github.com/Trikzon/expect-platform-test .

That repo will be deleted after this issue is solved.

Alternative expected package for Impls of @ExpectPlatform methods

Alternative expected package for Impls of @ExpectPlatform methods

Enhancement Description

Currently, when using @ExpectPlatform the implementation should be located as such:

com.examplemod.modid.foo.bar.FooBar (contains the @ExpectPlatform annotation)
com.examplemod.modid.foo.bar.fabric.FooBarImpl
com.examplemod.modid.foo.bar.forge.FooBarImpl

It would be great if instead, the expected package for Impls is as follows:

com.examplemod.modid.foo.bar.FooBar (contains the @ExpectPlatform annotation)
com.examplemod.modid.fabric.foo.bar.FooBarImpl
com.examplemod.modid.forge.foo.bar.FooBarImpl

Implementation Ideas

1. Somehow use the maven_group and archives_base_name (not ideal).
2. Require the "root" package to be initialized ExpectPlatform.setPackage("com.examplemod.modid");
3. Add an optional String parameter to the @ExpectPlatform annotation that specifies a package.

1.17 crashes when used with OptiFabric

Using

• OptiFarbic (1.11.1)
• preview_OptiFine_1.17_HD_U_G9_pre16
• architectury (2.0.7)

in MC 1.17 results in a crash

latest.log

`AddRefmapName` does not check if the refmap actually exists

1. make an empty mixin config
2. mixin will not generate a refmap
3. plugin will still add the refmap field to the mixin config

This doesn't cause a crash but causes warnings to be logged at runtime

Field injection targets don't get remapped in the refmap properly on Forge

When using Forge (this is with architectury), field injection points get remapped to intermediary in the refmap instead of srg. This causes the game to crash if using a field injection point.

Test source module does not include transformer agent/runtime libraries

As title states; setting up a test source set (in my case for game tests) does not include the agent and runtime libraries required for launching the game.

Workaround:
Adding the following to the dependencies block is a temporary workaround; run the ideaSyncTask after.

dependencies {
    testRuntimeOnly("dev.architectury", "architectury-transformer", "5.2.72", classifier = "agent")
    testRuntimeOnly("dev.architectury", "architectury-transformer", "5.2.72", classifier = "runtime")
}

Add `Fabric-Loom-Remap` to the Common manifest

When attempting to use an Arch project inside a Non-Arch-Loom, specifically where the common project uses loom instead of Arch loom or VanillaGradle libs that do not have Fabric-Loom-Remap defined in the jar manifest will cause loom to not properly remap the dependency.

I'll be honest, this is information from @modmuss50 and I don't fully understand the problem but adding this to the manifest fixes the issue. This is less a bug in Arch loom and more of a feature request for better cross build tools compatability.

Example of what needs to be added to the manifest.

jar {
    manifest {
        attributes 'Fabric-Loom-Remap': true
    }
}

Access widener from :common not applied in Fabric

Exact same build environment as in #45.

When trying to run Fabric 1.16.5 with an access widener placed in common/src/main/resources and properly referenced in fabric/src/main/resources/fabric.mod.json, I get the following crash:

[13:19:26] [main/ERROR] (FabricLoader) Uncaught exception in thread "main"
 java.lang.RuntimeException: Missing accessWidener file example.accesswidener from mod examplemod
	at net.fabricmc.loader.impl.FabricLoaderImpl.loadAccessWideners(FabricLoaderImpl.java:482) ~[fabric-loader-0.13.2.jar:?]
	at net.fabricmc.loader.impl.launch.knot.Knot.init(Knot.java:145) ~[fabric-loader-0.13.2.jar:?]
	at net.fabricmc.loader.impl.launch.knot.Knot.launch(Knot.java:71) ~[fabric-loader-0.13.2.jar:?]
	at net.fabricmc.loader.impl.launch.knot.KnotClient.main(KnotClient.java:23) ~[fabric-loader-0.13.2.jar:?]
	at net.fabricmc.devlaunchinjector.Main.main(Main.java:86) ~[dev-launch-injector-0.2.1+build.8.jar:?]
	at dev.architectury.transformer.TransformerRuntime.main(TransformerRuntime.java:219) ~[architectury-transformer-5.2.83-runtime.jar:5.2.83]

I am using a very similar setup to what is suggested through the architectury-templates template 1.16.5-forge-fabric-mixin.zip.
Going a bit deeper into this, the function ModContainer#getRootPaths suggests in its JavaDoc:

The paths may point to regular folders or into mod JARs. Multiple root paths may occur in development environments with -Dfabric.classPathGroups as used in multi-project mod setups.

Indeed, when adding the following to the VM options of the generated run configuration for IntelliJ, Fabric starts fine:

-Dfabric.classPathGroups=PATH_TO_PROJECT\fabric\build\resources\main;PATH_TO_PROJECT\common\build\resources\main

Of course, the fabric:runClient Gradle task still does not work correctly since the fix does not apply there.

I think, this should be applied/changed automatically by the Architectury plugin.

Edit: I just noticed a minor caveat: FabricLoader now logs:

[13:50:43] [main/WARN] (FabricLoader) getRootPath access for examplemod 1.0.0 with multiple paths, returning only one which may incur unexpected behavior!

I think, it's worth fixing this anyway - I just wanted to let you know...

Incorrect classpath in eclipse

Using ./gradlew eclipse generates the wrong eclipse classpath for the forge subproject.

The following would be an example of the changes needed to the generated forge/.classpath in architectury itself.

-
+

i.e. the forge project depends on the generated mcp jar rather than the common project directly

I can't see a trivial way to fix it from this page?
https://docs.gradle.org/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseClasspath.html

Built Fabric jar using incorrect refmap

When I try to build my JAR file for Fabric, I get this error:

 Mixin apply for mod kambrik failed kambrik.mixins.json:StructurePoolAccessor from mod kambrik -> net.minecraft.class_3785: org.spongepowered.asm.mixin.gen.throwables.InvalidAccessorException No candidates were found matching elements:Lit/unimi/dsi/fastutil/objects/ObjectArrayList; in net/minecraft/class_3785 for kambrik.mixins.json:StructurePoolAccessor from mod kambrik->@Accessor[FIELD_GETTER]::getElements()Lit/unimi/dsi/fastutil/objects/ObjectArrayList; [INJECT Applicator Phase -> kambrik.mixins.json:StructurePoolAccessor from mod kambrik -> Apply Accessors ->  -> Locate -> kambrik.mixins.json:StructurePoolAccessor from mod kambrik->@Accessor[FIELD_GETTER]::getElements()Lit/unimi/dsi/fastutil/objects/ObjectArrayList;]

StructurePoolAccessor is a Mixin in Kambrik, my mod.

I noticed that the .jar file contains a Kambrik-common-refmap.json. It's unused in kambrik.mixins.json. If I add the following line to kambrik.mixins.json:

	"refmap": "Kambrik-common-refmap.json"

The mod will launch successfully. As such, it seems that refmaps aren't being linked properly. I don't know much about how refmaps work, or how they're supposed to work, but this is what seems to be happening. It happens with ArchLoom 1.4-SNAPSHOT and 1.5-SNAPSHOT.

0.10.0: error loading MC classes on Fabric, TypeNotPresentException on Forge

• git clone --branch forge https://github.com/natanfudge/not-enough-crashes
• gradlew fabric:runClient: works
• IntelliJ Minecraft Client [:fabric]:
  
• gradlew forge:runClient / IntelliJ:
  

When you mixin into an inner class, the refmap will have the intermediary name, in both Forge and Fabric (and not srg in Forge)

Like here

@Mixin(targets = "net.minecraft.util.crash.CrashReportSection$Element")
public abstract class CrashReportSectionElementMixin {

The refmap will look like this (IN FORGE)

    "fudge/notenoughcrashes/mixins/CrashReportSectionElementMixin": {
      "net.minecraft.util.crash.CrashReportSection$Element": "net/minecraft/class_129$class_130"
    },

While everything else is properly mapped to srg:

    "fudge/notenoughcrashes/mixins/client/SplashScreenMixin": {
      "LOGO": "field_212973_a:Lnet/minecraft/util/ResourceLocation;"
    }

Remapping to MCP remaps access to synthetic methods in bootstrap methods incorrectly

Ok this is a very complicated issue, but long story short: the Mojmap to MCP remapper remaps methods it should not remap. When remapping to MCP, the remapper might take into account the usage of synthetic lambda$x$y methods in bootstrap methods. Here's an example of two bytecode reports of the same class on different loaders, the top one being that of forge and the bottom one being that of fabric:

I underlined the error: lambda$getMenuProvider$0 is not supposed to remap to func_220270_a, since it's a private, synthetic member of a class that belongs to the mod. Looking at the code I'm not sure whether the origin of this issue is the Architectury plugin or TinyRemapper, but my first thought is that it is Architectury, because the Mojmap to Yarn remapper uses TinyRemapper too and that one doesn't have the issue.

Allow the use of @ExpectPlatform without api

Add a dependency with just the annotations and inject the call site resolver into the compiled jar itself.

Loader deps are using + versions

It seems to cause dependency resolution issues (Fabricord) and they're also not good at all for reproducible builds.

architectury-plugin/src/main/kotlin/dev/architectury/plugin/ArchitecturyPluginExtension.kt

Line 432 in 0a37a6b

var envAnnotationProvider: String = "net.fabricmc:fabric-loader:+"

architectury-plugin/src/main/kotlin/dev/architectury/plugin/ModLoader.kt

Line 96 in 0a37a6b

envAnnotationProvider = "org.quiltmc:quilt-loader:+"

Refmap not being named correctly

Hi! In my project (https://github.com/ejektaflex/Bountiful), my Fabric refmap is not named correctly when I build the mods, and as such, the mod does not load in the final built jar.

Note that even though this is the Fabric jar file, it copied in the common refmap instead.
The problem is that the mixin json file is still referencing bountiful-fabric-refmap.json, which does not exist, so it causes a crash at runtime.

This might be a problem with my gradle setup - if it is, let me know what I've done wrong. Feel free to transfer it to the arch-loom issue tracker if it's better suited for there as well.

This didn't used to happen to me (I last did a build in July), so perhaps it's related to Arch-Loom 1.4 changes with a new snapshot? Not sure.

Quilt is considered Fabric for package replacement with ExpectPlatform

Pretty late so Ill elaborate later

Source code jars in maven

The source code for architecury-api uploaded to maven has a -dev classifier which I think is what it stopping getting downloaded when you run the gensources task?

FYI: Cloth config has the same issue, but REI looks to be doing right.

`Cannot read field "outgoingEdges" because "handlerRangeBlock" is null` for reading classpath (by Architectury Transformer)

Error:

"C:\Program Files\Java\jdk-19\bin\java.exe" -Dfabric.dli.config=E:\ChatTranslator\fabric\.gradle\loom-cache\launch.cfg -Dfabric.dli.env=client -Dfabric.dli.main=net.fabricmc.loader.impl.launch.knot.KnotClient -Darchitectury.main.class=E:\ChatTranslator\fabric\.gradle\architectury\.main_class -Darchitectury.runtime.transformer=E:\ChatTranslator\fabric\.gradle\architectury\.transforms -Darchitectury.properties=E:\ChatTranslator\fabric\.gradle\architectury\.properties -Djdk.attach.allowAttachSelf=true -javaagent:E:\ChatTranslator\.gradle\architectury\architectury-transformer-agent.jar "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2022.3\lib\idea_rt.jar=54801:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2022.3\bin" -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8 @C:\Users\tani\AppData\Local\Temp\idea_arg_file1270264523 dev.architectury.transformer.TransformerRuntime
[Architectury Transformer] Architectury Runtime 5.2.75
[Architectury Transformer] Read classpath in 1.658 s
Exception in thread "main" java.lang.NullPointerException: Cannot read field "outgoingEdges" because "handlerRangeBlock" is null
	at dev.architectury.transformer.shadowed.impl.org.objectweb.asm.MethodWriter.computeAllFrames(MethodWriter.java:1573)
	at dev.architectury.transformer.shadowed.impl.org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1547)
	at dev.architectury.transformer.shadowed.impl.org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:767)
	at dev.architectury.transformer.shadowed.impl.org.objectweb.asm.tree.MethodNode.accept(MethodNode.java:647)
	at dev.architectury.transformer.shadowed.impl.org.objectweb.asm.tree.ClassNode.accept(ClassNode.java:451)
	at dev.architectury.transformer.handler.SimpleTransformerHandler.toByteArray(SimpleTransformerHandler.java:231)
	at dev.architectury.transformer.handler.SimpleTransformerHandler.applyTransforms(SimpleTransformerHandler.java:203)
	at dev.architectury.transformer.handler.SimpleTransformerHandler.lambda$handle$1(SimpleTransformerHandler.java:80)
	at dev.architectury.transformer.input.FileView.lambda$handle$1(FileView.java:47)
	at dev.architectury.transformer.input.BaseFileAccess.handle(BaseFileAccess.java:82)
	at dev.architectury.transformer.input.FileView.handle(FileView.java:45)
	at dev.architectury.transformer.input.ForwardingFileView.handle(ForwardingFileView.java:47)
	at dev.architectury.transformer.input.ForwardingFileView.handle(ForwardingFileView.java:47)
	at dev.architectury.transformer.handler.SimpleTransformerHandler.handle(SimpleTransformerHandler.java:78)
	at dev.architectury.transformer.Transform.runTransformers(Transform.java:104)
	at dev.architectury.transformer.Transform.runTransformers(Transform.java:98)
	at dev.architectury.transformer.TransformerRuntime.main(TransformerRuntime.java:165)

Steps to reproduce:

• Use Minecraft Developement Plugin in JetBrains Intellj to create a new Architectury API mod.
• After the building is complete run any Minecraft Client loader.

Using:

• minecraft_version=1.20.1
• architectury_version=9.1.10
• fabric_loader_version=0.14.21
• fabric_api_version=0.86.0+1.20.1
• "architectury-plugin" version 3.4-SNAPSHOT
• forge_version=1.20.1-47.1.39

ResolutionException on Forge 37.0.29+

Good afternoon.

I'm using the Architectury Plugin 3.3 snapshot to develop for 1.17 on IntelliJ IDEA 2021.2 (CE). I don't use the IntelliJ-specific plugin. When I use the runClient run configuration with Forge 37.0.29 or above, I receive a ResolutionException. For example:

Exception in thread "main" java.lang.module.ResolutionException: Modules minecraft.mapped.loom.mappings.layered.hash.LOL1024.v2forge and forge export package net.minecraftforge.energy to module examplemod
	at java.base/java.lang.module.Resolver.resolveFail(Resolver.java:908)
	at java.base/java.lang.module.Resolver.failTwoSuppliers(Resolver.java:822)
	at java.base/java.lang.module.Resolver.checkExportSuppliers(Resolver.java:743)
	at java.base/java.lang.module.Resolver.finish(Resolver.java:379)
	at java.base/java.lang.module.Configuration.<init>(Configuration.java:140)
	at java.base/java.lang.module.Configuration.resolveAndBind(Configuration.java:494)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.ModuleLayerHandler.buildLayer(ModuleLayerHandler.java:70)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.TransformationServicesHandler.buildTransformingClassLoader(TransformationServicesHandler.java:61)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.Launcher.run(Launcher.java:104)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.Launcher.main(Launcher.java:77)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:26)
	at MC-BOOTSTRAP/[email protected]/cpw.mods.modlauncher.BootstrapLaunchConsumer.accept(BootstrapLaunchConsumer.java:23)
	at cpw.mods.bootstraplauncher.BootstrapLauncher.main(BootstrapLauncher.java:90)
	at net.fabricmc.devlaunchinjector.Main.main(Main.java:86)
	at dev.architectury.transformer.TransformerRuntime.main(TransformerRuntime.java:262)

I get a different exception every time I run it with different module and package names, but it's always a ResolutionException with the same stack trace.

The changelog for Forge 37.0.29 is Bump BootStrapLauncher, and make sure Capability providers call parent revive.. The related commit is fcc8195.

Solutions I've Tried

I've tried cleaning the project manually and with the Gradle tasks, re-importing the Gradle project, wiping my project and re-importing it from GitHub, invalidating caches through IntelliJ, and manually clearing my user .gradle folder to no avail.

Downgrading the Forge version to 37.0.28 or below resolves the problem.

I also searched GitHub to look for other repositories using the 3.3 plugin to see how they solved the problem, but nobody else appears to have tried using Forge 37.0.29+.

Steps to Reproduce

I initially encountered this issue while developing my mod, but I was able to reproduce it on the example mod provided by Architectury. This makes me believe that the problem is within the plugin and not my own project.

1. Clone the example mod repository and checkout the 1.17 branch.
2. Change the Forge version to 37.0.29 or above.
3. Generate run configurations with the genIntelliJRuns Gradle task.
4. Run runClient on the Forge subproject. A ResolutionException will appear after the mod files are discovered.
5. Downgrade the Forge version to 37.0.28, refresh the Gradle project, and runClient again. The game opens normally.

My mod doesn't use the Architectury API, and the issue still occurs.

neoforge and Quilt add support?

I would like to see support for the creation of neoforged and quilt added in intellj.

Unable to disable Legacy Mixin AP with Architectury plugin enabled

In loom 1.5 disabling Legacy AP became much larger, however arch plugin doesn't support this as it looks for refmap