https://gradle.com/ logo
Join Slack
Powered by
so, if I register a Provider as an extension, why ...
# community-support
c
so, if I register a Provider as an extension, why does gradle create a configure block. 
semver : Provider
semver { }
... but it's read only...
j
Why do you need to register a provider as extension?
c
because I thought 
semver.get().version
was better than 
semver.version.get().version
because maybe someday it could be 
version.set(semver)
j
I don't get your point
c
because otherwise, afaik there'd be no nice api for people to use
j
Can you show a sample about the fully code the user is going to write and consume?
c
sure, just read the lines I wrote above...
j
I don't follow that
Copy code
semver.version.get().version
that is weird I would expect
Copy code
semver.version.get()
c
it is weird
j
and even, consumers should not call 
get()
outside tasks
c
because the provider returns an object
j
so they would do 
myCustomPlugin.version.set(semver.version)
c
oh, on that one? go look at the ~4 or so bugs on how gradle publishing and anything related to it is NOT lazy
not my fault gradle publishing and the version property in gradle aren't lazy
you want to set 
version
in gradle with a provider? you have to call get
the object returned from the provider has a version property
j
They are going to modify that behavior and it will be 
Provider<String>
soon, so I would wait
c
so 
semver.get()
returns a 
Semver
soon (tm)
j
Gradle 9.0 if I remember correctly
c
we'll see
there's not a guarantee that the great propertyization is hitting the maven plugin
and in any sense me doing this is a step towards allowing that
so what would I wait for?
j
I would fill a bug for that
c
again, there are about 4, 2 of them are mine
j
it is a bit weird their task is calling it eagerly
e
in any case, it's consistent with all other extensions
why would 
Provider
be special-cased?
c
who's task? the maven plugin? yeah it's weird, but go ahead and put a logging statement in the pom portion of it... you'll see that that prints regardless of any task calls to publish
why would you generate configuration for things that can't be configured because they don't have properties/setters
anyways, the argument in my head was do I allow the nonsensical 
semver.version.get()
with the possibility that someone will want to do something with the 
version
property that is on the object returned from the 
get
note: in the future that could be the map or whatever
it's easier to talk about 
get
than any of a number of ways you can get the 
Semver
returned
anyways, if you must know, and maybe I should link the tickets in the README https://github.com/xenoterracide/gradle-semver that's got the why's
j
Why your plugin is not configuring directly the project version so the user does not need to do 
version = semver.get()
?
Anyway I have a Gradle Semver plugin and I setting a 
Provider<String>
like to the project 
version
, without any issue
c
because that could cause problems, and I've allowed a significant amount of flexibility
also providers aren't cached so...
so I do have to deal with that
I'm not certain what you mean by setting a provider string, but I"m not choosing what the user decides to do
there are many things that can be retrieved from the 
Semver
object
if someone wanted to change the output before they could
if I wrote it that would be ... harder
also then I think I'd have to put that environmentVariable code into the plugin
j
You can assign a 
Provider<String>
directly with your plugin and provide a 
map
like function in your 
semver
extension to allow the user to put whatever they want
Copy code
semver {
    map { 
        // do whatever with git branches, tags, etc.
    }
}
c
and that would solve what? and how would the environment trick I'm doing work?
assuming someone doesn't want to do that
j
btw I am publishing with my Gradle plugin
c
so?
I am too...
j
So probably your issue was not settings a 
Provider
that was overriding 
toString()
c
it does
j
Then that is weird, because it is working for me (and others)
c
or you mean the provider itself doesn't
what is working for you?
j
Settings a custom 
Provider<String>
which overrides 
toString()
to call `get()`on it
c
head desk
j
So if a third party plugin was doing 
version.toString()
inside a task, it was doing the correct thing
c
no, I am not trying to do that
and that seems silly
and solves what?
it doesn't make the calls to it any less eager
what's the correct thing exactly?
let's say I agree that it'd be better to have the extension be 
semver.version.get()
as I've went back and forth in that a lot. Is it really good to mix providers with configurable settings? that feels like the big reason to do that, is to not have another extension like semverConfig if I wanted there to be settings that affect what the provider. For example 
semverConfig.dirty.set(true)
would allow the version to contain dirty metadata, which causes a lot of thrash because every file change changes the configuration input.
4 Views
Open in Slack
PreviousNext
Powered by