Loom assumes an access widener will have a mod metadata property

[ChloeDawn]

Loom version: 0.5.42
I use an access widener for compile-time access transforming and cannot build my jar as Loom assumes that my access widener (which is not located in the source set path) will have a property in mod metadata, failing here:

fabric-loom/src/main/java/net/fabricmc/loom/task/RemapJarTask.java

Line 215 in 8657752

Preconditions.checkNotNull(awPath, "Failed to find accessWidener in fabric.mod.json: " + remapData.input);

[ChloeDawn]

The solution here would be to ignore the access widener if it is not located in the source set

[modmuss50]

Opps wrong issue.

[ChloeDawn]

Any update on this?

[modmuss50]

You should be able to disable this by doing:

remapJar {
   remapAccessWidener = false
}

Please let me know if that helps?

[ChloeDawn]

It seems to have no effect. I also tried in a doLast and it still results in the same error.

If I try in a doFirst I get:

The value for task ':remapJar' property 'remapAccessWidener' is final and cannot be changed any further.

remapJar {
  doFirst {
    remapAccessWidener.set(false)
  }
}

[ChloeDawn]

After a brief search online it appears to be related to modules, and may need further fixes in Loom

[modmuss50]

I havent looked into modules at all in loom, I have some plans but need to gain some input on what people will want.

I am creating a test for compile only access wideners atm, as it should work. The work around for now is to just include the AW in the jar.

[Chocohead]

You wouldn't want it in a doFirst or a doLast, it's a task property which means it should be being changed during task configuration time not task execution. As you're working on the default remapJar task things are configured a little late:

fabric-loom/src/main/java/net/fabricmc/loom/configuration/RemapConfiguration.java

Lines 77 to 80 in 429d2da

	if (isDefaultRemap) {
	extension.getUnmappedModCollection().from(jarTask);
	remapJarTask.getAddNestedDependencies().set(true);
	remapJarTask.getRemapAccessWidener().set(true);

So you'll want something like

remapJar {
	afterEvaluate {
		remapAccessWidener = false
	}
}

to configure it after Loom has done but before the task has started.

[modmuss50]

Yes, that should work.

I should look into making the remap jar task lazy to remove the need for the afterEvaluate, but thats something for 0.9 loom.

[ChloeDawn]

Attempting to use afterEvaluate results in

org.gradle.api.internal.AbstractMutationGuard$IllegalMutationException: Project#afterEvaluate(Action) on root project 'BeaconOverhaul' cannot be executed in the current context.

remapJar {
  afterEvaluate {
    remapAccessWidener.set(false)
  }
}

[ChloeDawn]

Ah I had to invert the scopes. This works:

afterEvaluate {
  remapJar {
    remapAccessWidener.set(false)
  }
}