*TLDR; I tend to wish the build files would stand as still as possible so I can focus on the rest of the application. *
I don't want to spend time learning new things about the build. If I haven't contributed for a while, the #1 impediment to re-starting is dealing with whatever changed about the build. The less it changes, the better. This doesn't mean we shouldn't improve it, just that I think we should not make developer-visible changes lightly. That's a nice list but can you provide examples of these things in *our* build? Your list sounds generic. When have these things held us back? Not wanting to learn groovy is similar to not wanting to learn kotlin unless we establish that a significant majority (much greater than 50%) of the community is (already!) familiar with kotlin and unfamiliar with groovy. Let me note that - "reduce the issues some people face" is going to also be paired with "introduce issues and learning curve for people who have been working with groovy/gradle builds for a decade" and - you mean "improve syntax highlighting" because there is (buggy) highlighting and completion for groovy in intellij... - And testability only (maybe) applies to scripts not the build. Not interested in changing just because language X is more popular than Y unless it's overwheliming preference in our community This was true of Groovy vs XML when we did the ant migration... XML was at the nadir of its popularity, and people were rabidly attacking XML on sight at that time. However, XML was NOT a reason I supported the ant to gradle migration, the ability to script cleanly, and the tightly integrated dependency resolution (without complicated additions like Ivy) were clear wins there. Ant's original stance was "declarative only, write tasks in java for programatic stuff", but the reality is even though ant tasks were fabulously easy to write, few people wanted to do it. The build for the build problem is irritating and we still have it in buildSrc builds in gradle. If using kotlin somehow eliminates the prebuild build that we have to do before configure phase runs, then THAT IS a win. (I doubt it does though). -0 for any build migration of any sort until there are clear problems in *our* build that actually will be solved via kotlin (and also until the most active current maintainers of the build say they like the idea) I guess I have the opposite affinity for the two halves (build vs script) from David since the question of scripting actually sounds like it solves a problem to me. If kotlin is good at general scripting (I haven't used it much) that, because then we *might* be able to support both windows and posix environments with a single script (but I also strongly suspect there are devils in the details there) If kotlin can improve support for widows, that solves a problem we do actually face. +0, interested for scripts but not +1 until demonstrated.... However, IMHO, part of the script's job is to *remain readable and tweakable*, so "compiled scripts" that have to be recompiled after editing are a solid -1 for me, and therefore, we do need to justify the added environmental dependency (including version!) or include our preferred version of kotlin in the distribution (I beleive it is ASL 2.0 so perhaps possible), and then shipping it will place boundaries on our JVM compatibility.... -Gus On Fri, Feb 13, 2026 at 10:07 PM David Smiley <[email protected]> wrote: > I'm +1 on switching from Groovy to Kotlin in our **Gradle build files**. > Gradle has excellent support for it, as does IntelliJ, and I'm rather fond > of Kotlin, having used it once. I look forward to editing these files with > better IDE assisted type awareness and less magic/voodoo. > > But I'm unsure about the broader scope you speak of. > > On Fri, Feb 13, 2026 at 8:02 PM Christos Malliaridis < > [email protected]> > wrote: > > > Hello everyone, > > > > I'd like to discuss here and in our meetup on Wednesday our current state > > of our build files and scripts. I'd like to propose a possible migration > > that will add many benefits, listed below. > > > > The migration is about replacing all our python scripts and groovy build > > files with Gradle Kotlin DSL. This would > > - reduce the issues some people face with our scripts (like me) > > - improve the compatibility with operating systems > > - reduce the dependencies to environment constraints > > - add testability to these files > > - cleans up old stuff > > - add syntax highlighting, IDE support and code completion > > > > Therefore, besides this discussion here, I'd also appreciate your > > participation in our meetup next week. > > > > What are your thoughts on this? We are already using Kotlin for the new > UI, > > so why not use it more so folks get more familiar with it? > > > > Best, > > ChristoS > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
