Work on better include configuration
#1080
Conversation
src/main/java/net/fabricmc/loom/build/nesting/NestableJarGenerationTask.java
Outdated
Show resolved
Hide resolved
| private static final Pattern SEMVER_PATTERN = Pattern.compile(SEMVER_REGEX); | ||
|
|
||
| @InputFiles | ||
| @PathSensitive(PathSensitivity.NAME_ONLY) |
There was a problem hiding this comment.
The only part of the path to the jar to nest that affects the output is it's name and contents; the relative/absolute path is irrelevant
| String version = moduleLocation.version; | ||
| String classifier = null; | ||
|
|
||
| if (artifact.getFile().getName().startsWith(name + "-" + version + "-")) { |
There was a problem hiding this comment.
Shame there is no better way to get the classifier, this seems quite fragile.
There was a problem hiding this comment.
Yeah unfortunately this is the only way to do this (without doing the questionable approach it did before); classifiers are a maven concept that doesn't translate super well into gradle. I'd encourage people to use capability requests and feature variants instead.
All that said -- this was the workaround I found on a relevant gradle issue about the lack of a way to query artifact classifier (I can try to track that down later), and it should actually be pretty stable given that the classifier and extension provided are used only while gradle is resolving which artifact of a module to use; so if something was selected by classifier it should be in the name. At any rate, probably less fragile than the old system still.
There was a problem hiding this comment.
See gradle/gradle#23702 -- basically, at the level we're operating at we're in variant aware resolution, and gradle doesn't really care about classifiers at that level because they're a very maven concept, so they're not there
Co-authored-by: modmuss <[email protected]>
Currently, the
includeconfiguration uses dependency resolution information at runtime; additionally, it works based off ofDependencyobjects, which is generally speaking a bad way to pass dependency information into a task - we're meant to use the various dependency resolution result types instead. All of this combined means that the system is not very future-proof. This PR is an attempt to modernize the system, while keeping the old behavior.