https://gradle.com/ logo
Join Slack
Powered by
Will it be impossible to have custom functions to ...
# declarative-gradle
j
Will it be impossible to have custom functions to be called inside of dcl even if they receive only basic params? Looks like everything around this has been deleted or is internal (for example, 
implementation(…)
can be used but the APIs are internal).
I think this limit has no sense. It will be blocking the usage to a very limited amount of tools, for example, version catalogs, projects, etc. If something, even being official, is not available, you are blocked (something is currently happening). But that is too opinionated, if I have a custom random implementation based on a txt file instead of using version catalogs, you cannot workaround that because you cannot have your custom functions even if they only accept a single string as parameter. More samples: accepting any local property, Gradle property, environment variable or even a custom implementation of .env that does not exist yet on this ecosystem.
I understand the decision about being explicit in the build declaration, but I do not agree at all with the expected result. If my DSL has a 
customProp
that gets a version from env, gradle properties, local properties, or whatever.
Copy code
format {
    ktfmt {
        version = customProp("ktfmtVersion")
    }
}
Banning that behavior just to get "explicit" build will be just hiding under a rug (custom included build with custom implementation) the issue. Obviously 
customProp
can be a good name to know what is indeed happening by just reading the name of the function. So instead of seeing easily what is happening in the build, with no included build or no knowledge about the build itself, the DCL will be:
Copy code
format {
    ktfmt {
        // ktfmt version is changed "magically" if you aren't the build author.
    }
}
And the version is just wired in the included build, no way to see that easily in the DCL, if you know nothing about the included build, it is just magic. I hope I am missing something and this is possible to be done.
p
You can have custom functions, in some way. But keep in mind, one goal of DCL is also tooling support, to update your DCL file from IntelliJ. With arbitrary custom functions, this goal is not easily possible.
And you can also have your own txt file based version catalog, if you want to, via a settings plugin.
Regarding assignment of env vars/gradle properies, I agree, it should be possible
j
I really understand that, indeed I have an example I understand it will not be supported in any way, this 
mapVersion
Copy code
semver {
    tagPrefix.set("v")
    mapVersion { gradleVersion: GradleVersion ->
        val kotlinVersion: String = getKotlinPluginVersion()
        "${gradleVersion.copy(metadata = kotlinVersion)}"
    }
}
But I need a way to at least have simple functions like 
implementation
.
Can you point me to that part where it shows how to create custom functions? I have found only internal things. The old annotations are deprecated/removed.
p
There is no implementation function. implementation is a DependencyCollector and Gradle generates an invoke function for some parameters.
j
Will check that, thank you!
implementation is a DependencyCollector and Gradle generates an invoke function for some parameters.
Can I have my own "Collector" so Gradle generates the functions? I am checking the 
StandardLibraryComponent
and it is full of internal APIs, and I guess that the magic is done by: • 
AnalysisSchemaComponent
• 
ObjectConversionComponent
Both are internal
p
What exactly do you want to do?
Of course you can create your own custom nested dependencies block with dependencycollectors
Or a function that returns a ExternalModuleDependency
Before trying to create custom functions, you should try to use a Gradle native way/feature
j
I will check the DependencyCollector to see if that works to get the version for ktfmt
2 Views
Open in Slack
PreviousNext
Powered by