Unable to set classifier correctly for jar archives

Version: 0.8.21

No effect (ideally this is the approach that should work as expected):

tasks.jar {
	archiveClassifier.set("foo")
}

---

Produces a JAR with the correct classifier, but -dev jar with no prepended classifier:

afterEvaluate {
	tasks.remapJar {
		archiveClassifier.set("foo")
	}
}

Example-1.0.0-dev.jar
Example-1.0.0-foo.jar

---

Produces an error:

afterEvaluate {
	tasks.jar {
		archiveClassifier.set("foo")
	}
}

OR 

afterEvaluate {
	tasks.jar {
		archiveClassifier.set("foo")
	}

	tasks.remapJar {
		archiveClassifier.set("foo")
	}
}

A problem was found with the configuration of task ':remapJar' (type 'RemapJarTask').
  - In plugin 'net.fabricmc.loom.LoomRepositoryPlugin' type 'net.fabricmc.loom.task.RemapJarTask' property 'input' specifies file '...\build\libs\Example-1.0.0-dev.jar' which doesn't exist.

[Juuxel]

As a side note, the same afterEvaluate overuse leads to not being able to change other properties outside of afterEvaluate, like remapAccessWidener in Adorn. Even the archive classifier that I set above would be broken, but Loom (luckily for me?) uses the deprecated setClassifier instead of getArchiveClassifier().set() so it’s only used as a fallback.

Really, all of this code needs to be changed to a) use Property instead of deprecated archive task methods, and b) not be in afterEvaluate.

[Juuxel]

Loom doesn’t base the classifier edits for the default jars on the current remapJar classifier. (The classifier for named jars doesn’t really matter considering they’re not all that useful)

Loom just sets the jar task’s classifier to be dev unless you modify it, so if you really want fabric-dev, you also need to add jar { archiveClassifier.set("fabric-dev") }.