https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
c
a goal for subprojects would be for the build script to be quite minimal, using one or more convention plugins to do the setup. generating code/build scripts that you have to maintain/evolve isn’t a great practice.
b
Agree, the majority of it is honestly directory structure and specifying one convention or another
c
you could have a convention plugin expose a custom “init subproject” task (perhaps it differs by type of subproject) that creates standard directories etc. Makes the creation of a subproject: • base dir • build.gradle.kts that includes the convention plugin(s) • run init task to create directories (assuming this is worthwhile to do so, perhaps creating them manually is fine)
a
Gradle is pretty limited when it comes to interactive input https://github.com/gradle/gradle/issues/2842
c
yea. usually find it better to create a task with options and provide those on the command line rather than prompt.
a
if you wanted to make an interactive task you could just make a 
blah.main.kts
script and use Clikt?
there’s some internal Gradle functionality for requesting for input from a user https://github.com/gradle/gradle/issues/1251#issuecomment-512710561 I think UserInputHandler is intended for the Init or Scan plugins?
c
would question whether subprojects (components of a larger system) should really have free-form structure (prompted from user) - would expect them to follow standardized patterns.
b
you could have a convention plugin expose a custom “init subproject” task (perhaps it differs by type of subproject) that creates standard directories etc.
That's an interesting option! I haven't thought of that Maybe combining that with some commandline options would be Good Enough territory for now
if you wanted to make an interactive task you could just make a 
blah.main.kts
script and use Clikt?
Interesting, I'm an absolute Kotlin newbie so thanks for the Clikt reference
I think UserInputHandler is intended for the Init or Scan plugins?
Yes, I looked into the init plugin code to see how it does things, and it's all in an internal directory. It does seem like there's (currently) nothing exposed But thanks for the pointers, I'll look into some of the alternatives
Actually could you maybe please elaborate on the 
blah.main.kts
part? Do you mean for that to be as part of the project? How would someone run it?
a
you’re not supposed to use Gradle functionality inside of a 
internal
package… but that’s only because the Gradle team can change it without warning. If you just want to make a tool for a local project, and it doesn’t matter if it randomly breaks when you update Gradle, then I’d just use UserInputHandler (especially because you’d be using it for a util that’s not critical, and can be done manually if desired)
Actually could you maybe please elaborate on the 
blah.main.kts
part? Do you mean for that to be as part of the project? How would someone run it?
Sure thing! anyone can run a 
*.main.kts
script so long as they have Kotlin installed on PATH (e.g. 
brew install kotlin
and then 
./blah.main.kts
) Kotlin Scripting is still in early stages, but it’s nice because you can write regular Kotlin code rather than Bash scripts, and that tends to be more readable and easier to maintain. And okay, it’s more difficult to access all of the other cli utils so the scripts will be more verbose than a shell script equivalent, but a .kts script will be more compatible on on different OSes. For example, I wrote a kts script for publishing a Gradle Plugin release https://github.com/adamko-dev/dokkatoo/blob/9e1c87e5c65bc3fe5bde8d47a5be23c20f935533/devOps/release.main.kts. It uses Clikt to get the version to release, and calls the GitHub CLI to create PRs and wait for releases. It’s still very rough around the edges though. So if you wanted to have an interactive script, to help with project set up, then I think a .kts is a good idea. You could ask the user for the type of project to make, and just then create some functions in the script that would create some directories and a build.gradle.kts with the convention plugins applied.
👀 1
b
If you just want to make a tool for a local project, and it doesn’t matter if it randomly breaks when you update Gradle
That's true, updating gradle would be done by someone who knows the infra so they can update both in lockstep
You're right, I don't know why I didn't think of just straight up using kotlin, it felt like it needed to be through gradle, but it really doesn't Thanks a lot for your time and input! I appreciate it
6 Views
Open in Slack
PreviousNext
Powered by