-
-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gradle cleanup #645
base: 24w40a
Are you sure you want to change the base?
gradle cleanup #645
Conversation
…round proposer conflicts, make simple_type_field_names_path an input of insertAutoGeneratedMappings task, make 'id' simple type name exclusive
Co-authored-by: Eli Orona <[email protected]>
…ames rename IdListUtil#sortArray -> createByIdGetter make enums that use createByIdGetter consistent restore SpawnReason add simple type names for Entity+LivinEntity add stub FindInvalidSimpleTypeFieldNamesTask class map a few other things along the way
…simple type names)
…bettererly move EnigmaProfile to MappingsExtension
…asks should not be retreived by type alone, adding a new task with the same type would break things (most calls to MappingsTask::getTaskNamed will probably be eliminated when configuration is moved to MappingsPlugin) the thisening the abstractening the finalening the line wrappening
Early reviewers beware: I will probably be rewriting history so any review progress on github may be lost. |
add missing get() to extractServerJar
…guration to MappingsPlugin refine downloadWantedVersionManifest inputs/outputs
…tion to MappingsExtension refine their properties and dependencies make ExtractServerJarTask's getServerBootstrapJar() an input instead of an output make downloadMinecraftJars not finalizedBy extractServerJar as input/output handling is preferable
…figuration to MappingsPlugin rework both tasks' inputs and outputs significantly downloadMinecraftLibraries is still screwy though: it accesses and modifies project in its task action add Task suffix to OpenGlConstantUnpickGenerator class rename PropertyUtil -> ProviderUtil and add projectDirProviderOf
…operties, and separated ExtractTinyMappingsTask added ExtractTinyMappingsTasks for hashed and intermediary removed DownloadIntermediaryMappingsTask class, it's just a DownloadMappingsTask now added Constants.INTERMEDIARY_MAPPINGS_NAME, but haven't replaced duplicates yet made some convensions in MappingsPlugin to use flatMap instead of lambdas move MappingsExtension's getEnigmaProfileFile convension to MappingsPlugin
…diaryTask to MappingsPlugin refine their and their superclass' properties
afcb886
to
6391a20
Compare
🚨 Target branch is already set to 24w39a |
🚀 Target branch has been updated to 24w40a |
🚨 Please fix merge conflicts before this can be merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good! Unsure if the eventual aim is config cache here (and maybe it ought to be, as config cache will be on by default in gradle 9 which is on the horizon) -- regardless, if so there's a bit of work to do, since a lot of stuff is still kinda unidiomatic in that regard; all things told though a drastic improvement. Didn't comment on any remaining TODOs.
public MappingsExtension(Project project) { | ||
this.fileConstants = new FileConstants(project); | ||
|
||
this.enigmaProfile = this.getEnigmaProfileFile() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
map
ed providers are not cached, and I assume this is used in several placed -- so instead of having, say, a public final Provider<EnigmaProfile> enigmaProfile
, have a Property<EnigmaProfile>
and set
it to the mapped provider, which is cached
task.getMappingDirectory().set(mappingLintTask.getMappingDirectory()); | ||
mappingLintTask.dependsOn(task); | ||
public void apply(@NotNull Project project) { | ||
final var ext = project.getExtensions().create("mappings", MappingsExtension.class, project); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really a big deal, but the Project
can just be @Inject
ed here.
"Up-to-date-ness is ensured by getSimpleTypeFieldNamesFiles and its source, " + | ||
"MappingsExtension::getEnigmaProfileFile." | ||
) | ||
public abstract Property<EnigmaProfile> getEnigmaProfile(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is enough for build cache, but won't get you to config cache -- all task properties need to be serialize-able or transient (in which case they may not exist at task runtime), @Internal
or @Input
s or @Output
s or whatever. Question for your consideration: is there ever more than a single EnigmaProfile
created by this plugin, at all? If the answer is no, use a build service!
@Internal( | ||
"An EnigmaProfile cannot be fingerprinted. " + | ||
"Up-to-date-ness is ensured by getSimpleTypeFieldNamesFiles and its source, " + | ||
"MappingsExtension::getEnigmaProfileFile." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is MappingsExtension::getEnigmaProfileFile
ever actually marked/added as a task input? Or is the only stuff from it that can affect stuff the simpleTypeFieldNamesFiles?
} | ||
|
||
decompiler.decompile(getInput().getAsFile().get(), getOutput().getAsFile().get(), options, libraries); | ||
decompiler.decompile(this.getInput().getAsFile().get(), this.getOutput().getAsFile().get(), options, libraries); | ||
} | ||
|
||
@Internal | ||
public AbstractDecompiler getAbstractDecompiler() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to the EnigmaProfile stuff above -- this is not conf cache compatible, and looks like a perfect place to use a build service.
@OutputDirectory | ||
public abstract DirectoryProperty getLibrariesDir(); | ||
|
||
@Internal("Fingerprinting is handled by getLibrariesDir") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
public abstract RegularFileProperty getPerVersionMappingsJar(); | ||
|
||
@Input | ||
public abstract MapProperty<String, File> getArtifactsByUrl(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a sneaking suspicion this is meant to be @InputFiles
, if you're using the artifacts' contents.
import org.gradle.api.tasks.Internal; | ||
import org.gradle.api.tasks.OutputFile; | ||
import org.gradle.api.tasks.TaskAction; | ||
import quilt.internal.Constants; | ||
import quilt.internal.tasks.DefaultMappingsTask; | ||
|
||
public class CheckTargetVersionExistsTask extends DefaultMappingsTask { | ||
public abstract class CheckTargetVersionExistsTask extends DefaultMappingsTask { | ||
public static final String TASK_NAME = "checkTargetVersionExists"; | ||
|
||
@Internal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh... I don't like whatever this is doing. Does it set the field during task execution then expect tasks running after it to grab the field from the task and use it? Iffy, to say the least, though I suppose functional. Regardless -- I'd annotate the method, not the field, here in either case.
public static final String TASK_NAME = "checkUnpickVersionsMatch"; | ||
|
||
@InputFile | ||
private final RegularFileProperty unpickJson; | ||
public abstract RegularFileProperty getUnpickJson(); | ||
|
||
@Internal | ||
private boolean match = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as my worry with targetVersion above -- I'm not quite sold on this approach, it seems like a bit of a bad pattern.
// TODO eliminate this task (or make it a super class of tasks that currently depend on it) | ||
// Tasks that depend on it should instead take the intermediary configuration as input and check if it exists and | ||
// can be resolved | ||
public abstract class CheckIntermediaryMappingsTask extends DefaultMappingsTask { | ||
public static final String TASK_NAME = "checkIntermediaryMappings"; | ||
|
||
@Internal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooh, here's another of whatever-the-heck these are!
Based on #643 because it builds on it a bit.
Will also have to wait for #644.
Tasks:
MappingsPlugin
(makes it easier to see dependencies and makes tasks more reusable)MappingsExtension
buildSrc
referencingbuild.gradle
thingsbuildSrc
?