https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
v
What do you mean by "dynamic"?
j
ive noticed some tasks, like the maven publish tasks such as "publishMavenJavaPublicationToMavenRepository" don't exist if i try to add a dependency on them, even within a plugins.withType closure
but they do exist if i put that code in an afterEvaluate
v
What do you mean with "even within a plugins.withType closure" exactly? What is your code that is not working?
j
in this case, like
Copy code
plugins.withType<MavenPublishPlugin> {
            
        }
i dont have an exact snippet b/c i have avoid writing this code for these types of tasks because of this issue, but i am rethinking it and wondering if ther eis a better way
yeah i know, its plugins.withType
to make sure the code doesnt run until after the plugin is loaded
v
Ya, sorry, thought 
tasks.withType
j
i can experiment aroudn with tasks.named, but i was wiondering if anyone knew offhand if th at works
v
tasks.named
only works if a task is already registered.
j
ok. yeah i think the issues with these tasks are that they arent registered explictly
v
If you can restrict by task type (to avoid realizing all tasks) you can do things like 
tasks.withType<...>().matching { it.name == "..." }
j
its some kind of pattern that is dynamically evaluated
i am not sure how they work tbh
v
No, they should be registered explicitly, depending on the configuration of the publishing extension
Dynamic tasks handled by task rules are a different topic maybe
j
ah, well it could be that i unfairly lumped these tasks in then. it does seem they are registered during plugin application
but how is it possible, if additional repositories and publications can be declared int he build script? would those configurations evaluate after the plugin is applied?
v
Actually all these work here:
Copy code
val foo by tasks.registering {
    dependsOn(tasks.withType<PublishToMavenRepository>().matching { it.name == "publishMavenJavaPublicationToMavenRepository" })
}
Copy code
val foo by tasks.registering {
    dependsOn(tasks.named("publishMavenJavaPublicationToMavenRepository"))
}
Copy code
val foo by tasks.registering {
    dependsOn("publishMavenJavaPublicationToMavenRepository")
}
The first of course realizes all tasks of that type.
The second does only woks here because of task configuration avoidance. If 
tasks.named
does not work, that is a sign that the dependee task is maybe realized a little bit early and thus the dependency is not yet registered by the plugin. But first and third way even work with 
tasks.creating
and thus eager realization.
And it also depends on order. The task is not registered on plugin application. The plugin listens to instances added to the 
publications
and 
repositories
containers of the 
publishing
extension and if either is added, the respective tasks are registered.
So in my tries I had the 
foo
configuration before the 
publishing
block. But if I move it after the 
publishing
block, again all three variants work fine, even with eager configuration, as then the tasks are registered already.
j
ahhhh ok thats the piece i was missing
Thanks!
v
yw
vote for my CC Hackathon PR 🙂 (#CA7UM03V3)
👍 1
Open in Slack
PreviousNext
Powered by