-
Notifications
You must be signed in to change notification settings - Fork 5k
Update AbstractArchiveTask to expose Provider API #7435
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
Update AbstractArchiveTask to expose Provider API #7435
Conversation
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.
Should this TODO be removed now?
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.
Yep, I think so
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 didn't really want this to show up in the generated docs, so I left it using the implNote
tag, hope that's okay.
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.
Yeah, it looks like the version of javadoc we're using doesn't like @implNote
. You could also put this as a comment inside the method too.
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.
If anyone has a better name for this, let me know.
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.
getExtension
is the best name, but it's already taken. Maybe getArchiveExtension
?
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.
getExtension
is already taken, I'll use getArchiveExtension
.
e99e9a3
to
9b4c427
Compare
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.
Thanks for taking the time on this. I've left some comments.
The test failures are due to the convention mapping no longer working from BasePlugin
. We'd need to change
gradle/subprojects/plugins/src/main/java/org/gradle/api/plugins/BasePlugin.java
Lines 92 to 106 in c78d05f
Callable<File> destinationDir; | |
if (task instanceof Jar) { | |
destinationDir = new Callable<File>() { | |
public File call() throws Exception { | |
return pluginConvention.getLibsDir(); | |
} | |
}; | |
} else { | |
destinationDir = new Callable<File>() { | |
public File call() throws Exception { | |
return pluginConvention.getDistsDir(); | |
} | |
}; | |
} | |
taskConventionMapping.map("destinationDir", destinationDir); |
to something like:
if (task instanceof Jar) {
task.getDestinationDirectory().set(project.getLayout().getBuildDirectory().dir(pluginConvention.getDistsDirName()));
} else {
task.getDestinationDirectory().set(project.getLayout().getBuildDirectory().dir(pluginConvention.getLibsDirName()));
}
And deprecate the BasePluginConvention.get*Dirs methods.
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.
Yep, I think so
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.
Could you make this a regular default constructor?
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.
Sure.
It just seemed clearer to have this logic as close to where the field was declared as possible.
Happy to change it.
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.
Please make this final
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.
Agreed!
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.
Please make this final
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.
Agreed!
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.
Thanks for fixing all of these!
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 think our checks will want @since
tags in the javadoc for all new methods.
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.
Could you also add destinationDirectory
and the new extension method below to subprojects/docs/src/docs/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.xml
as properties?
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.
Sure. What is subprojects/docs/src/docs/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.xml
?
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.
Done, I think.
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 think @marcphilipp just added this.
I think the behavior with the Provider/Property is that the error will be about an unset provider?
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.
There's still an exception thrown, it's a different exception now though and it happens at a different phase in the build.
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.
getExtension
is the best name, but it's already taken. Maybe getArchiveExtension
?
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.
Yeah, it looks like the version of javadoc we're using doesn't like @implNote
. You could also put this as a comment inside the method too.
Before this change, there was no easy way to rely upon the output of the AbstractArchiveTask without using dependsOn. Related: https://github.com/gradle/gradle-native/issues/893 Signed-off-by: Jonathan Leitschuh <[email protected]>
Signed-off-by: Jonathan Leitschuh <[email protected]>
9b4c427
to
4c5e939
Compare
Signed-off-by: Jonathan Leitschuh <[email protected]>
} | ||
}; | ||
} | ||
task.getDestinationDirectory().set(project.getLayout().getBuildDirectory().dir(project.provider(destinationDir))); |
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.
Thank you @big-guy for working on this with me!
Signed-off-by: Jonathan Leitschuh <[email protected]>
4d68c55
to
a6abefd
Compare
Signed-off-by: Jonathan Leitschuh <[email protected]>
c92f28f
to
666240a
Compare
Supposedly I introduced some binary incompatibility?? @big-guy can you tell me what that means so I can try and fix it? |
Thanks @JLLeitschuh, I merged this locally, fixed a couple of things and pushed it to master. This'll be in 5.1 |
Thanks! |
Before this change, there was no easy way to rely upon the output
of the AbstractArchiveTask without using dependsOn.
Related: https://github.com/gradle/gradle-native/issues/893
Signed-off-by: Jonathan Leitschuh [email protected]
Contributor Checklist
<subproject>/src/integTest
) to verify changes from a user perspective<subproject>/src/test
) to verify logic./gradlew <changed-subproject>:check
Gradle Core Team Checklist