https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
How do they need to "learn Kotlin" if they only modify "dependencies, includes, excludes etc"? Syntaxwise it should practically be the same. And up to now they have to "learn Groovy". 🙂
🏎️ 1
t
If it's simple enough, then it shouldn't be more "learning Kotlin" than you're currently asking them to "learn Groovy".
🐌 1
c
Nobody is asking them to “learn Groovy” they already know it. If I migrate now (or in the future) to Kotlin I’ll be asking them to learn Kotlin in addition.
v
But it is trivial for the use-case you described, isn't it? They don't need to learn much Kotlin. Besides that noone forces you to change to Kotlin DSL, it is just promoted more to use it due to its pros by generating it by default and showing it first when opening the userguide. But I don't think Groovy DSL will be dropped "anytime soon" or ever.
c
I guess I’m trying to understand if the position is either: 1. Kotlin is the future, Groovy is legacy. 2. Kotlin is the statically typed way, Groovy is the dynamically typed way, both are valid, but we prefer static.
v
My totally uneducated guess is 2. But I'm just a user like you, so I don't know. 🙂
p
Groovy is and will stay supported. 2. it is
👌 1
👍 1
s
you can always do it in bits and pieces. that's the way to do it. sneak it in 😉 plus honestly...it pretty much looks the same. if i see groovy code i can convert it to kts. there are just some oddities sometimes if you've got multi project builds and convention plugins. but you'd get a lot of those w groovy anyway
one thing i was wondering, if gradle had any plans to make arguments/params discoverable. i suspect this is actually becuase of the non-static limitations of groovy. basically, if i run a task in intellij and start typing "gradle mytask", i would expect it to be able to autocomplete that i want to pass in 
gradle mytask -PdoStuff
. the current setup makes these non discoverable. you have to poke around and hope you find it, versus autocomplete telling you the possible options that would be a huge QOL for me, and i suspect for others...
v
If 
doStuff
is for 
myTask
and meant to be supplied on the commandline, make it an 
@Option
instead. Project properties are not "assigned to" something, so you can hardly have some autocompletion unless whoever reads the property would additionally register it with some lookup registry. The 
@Options
are afair also not autocompleted in the IDE, but that could maybe be added. Not that this topic has anything to do with the current thread. 😄
s
@option instead of parameter you mean? i'm unfamiliar with how those params currently get described in plugins the context i'm thinking of is this: https://axion-release-plugin.readthedocs.io/en/latest/ ./gradlew markNextVersion -Prelease.version=1.0.0 so, ideally the plugin should switch that to use an @Option .. and then is that with -Drelease. ? was reading the docs on best practices but i thought params were the way to go there
v
No, not 
-D
that would be a system property.
@Option
are like 
gw markNextVersion --version 1.0.0
You can of course also support both, 
@Option
for commandline usage given for a specific task, project property for configuring it in Gradle property files.
Anyway, all I'm saying is, that 
@Option
is more likely to be made auto-completable, I guess that is just missing functionality in IntelliJ
s
hmmm okay, thank you
3 Views
Open in Slack
PreviousNext
Powered by