This is the discussion I am seeking, thanks a lot David and Gus. I hope it will help us evaluate the proposal I am making.
> Gradle has excellent support for it, as does IntelliJ This was the main trigger of this proposal. I miss the documentation and proper highlighting in IntelliJ for the build files that I am looking into every now and then. > I don't want to spend time learning new things about the build. I understand. The time needed to learn a new language should not be taken lightly. I believe that the Kotlin DSL is syntactically very similar to Groovy with only small differences, so it should be very easy to read and learn. An example what it means to migrate can be found in [4], where I migrate the build.gradle and settings.gradle to build.gradle.kts and settings.gradle.kts. If you use IntelliJ and checkout the branch, you will see the difference in the IDE support I wish for. With "reduce the issues some people face" I am referring to my experience with all the python scripts that we have, that are not working on my machine (Windows) and also didn't work out-of-the-box on my Mac. As you may know, Windows users come with 2+1+1 terminals, the CMD, powershell, Git Bash (since you usually install git with a bash) and WSL. All have different behavior when it comes to path resolution or environment variables in scripts and tools that are expected to be installed and configured on the machine. One of the tools used in our smoke tester script (gpg) had even different options on Windows. > That's a nice list but can you provide examples of these things in *our* build? I believe there are enough cases where the topics I mention were an issue: - Compatibility with operating systems like Windows is a problem which was discussed recently - With Kotlin I had positive experience writing OS-independent build files that interacted with files and file paths. One example related to our project would be [4] - Our Solr scripts (bin/solr and bin/solr.cmd) for running and launching solr had and still have bugs and challenges, mainly because of the platform-specific dependency (see for example [7] and [8]) - Some time ago I created a CLI sub-module written in Kotlin [3] that could replace our solr scripts (bin/solr and bin/solr.cmd). It would add testability for all operating systems and without the need of an additional testing framework (see also [6]). Code duplication would also be addressed this way. - [1] would be an example for the environment constraints that are causing issues in our CI/CD - I believe without enough knowledge that some pre-Lucene-Solr-split stuff is lying around in the build files, perhaps [9] and [10]? - Another benefit of using Kotlin would be to have more people getting familiar with it, so more people could contribute to the new UI of Solr in the future Most of the problems are solvable, yes, and they are usually platform-specific. But the platform constraints we currently have give new devs a difficult start. So I believe we should reduce them as much as possible. After all, I believe we don't want the project to limit the platforms developers are using. > "introduce issues and learning curve for people who have been working with groovy/gradle builds for a decade Yes, that is indeed a topic worth discussing. The goal is not to introduce new issues by migrating to Kotlin. And a learning phase is inevitable when switching languages, obviously. But I believe Kotlin DSL has done a great job in keeping a steep learning curve. See gradle files from [4] as an example. If we manage to replace python scripts with Kotlin DSL, we would not need python in the environment. A resolution of a recent issue seems to be related to that [1]. There is obviously no perfect solution, and always developer preferences that influence these decisions. Gradle Builds switched to Kotlin DSL some time ago, and the reasons are well-described in this article [2]. I believe proper IDE support is one of the main improvements I am looking for, as I had some hard time writing working Groovy configurations with a trial-and-error approach. > And testability only (maybe) applies to scripts not the build. For build files it depends. I have seen a lot of logic in our build files that, if refactored, could include some tests as well. The question is do we need tests for these parts? > -0 for any build migration of any sort until there are clear problems in *our* build that actually will be solved via kotlin For that I may not know the gradle builds well enough. So except the IDE support and current complexity of our build files that costs me more time than necessary whenever I touch them, I don't have good reasons prepared. So I'd like to forward this request to others, maybe there are people out there that face some problems worth mentioning now? Without being able to support my opinion, I believe our build files are more complicated than necessary due to the history Solr and Lucene had together. > [...] and also until the most active current maintainers of the build say they like the idea If we plan to proceed with this topic, initiating a vote would be worthwhile. > +0, interested for scripts but not +1 until demonstrated.... I think [3] and [4] could be candidates for this? I am willing to migrate a script of your choice too if you have a preference. > 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 I believe Kotlin scripting [5] would be possible, but likely not recommended due to its current state. May I ask why compiled scripts would be a problem? I am considering Gradle tasks for replacing our custom scripts. They would still be executed through a single ./gradlew call. Not sure if that is a deal-breaker for some cases I am not aware of? > and therefore, we do need to justify the added environmental dependency (including version!) This is already the case for python scripts, if I am not mistaken. On the other hand, Kotlin scripts (or at least Gradle Kotlin DSL) would be maintained by our current dependency management system and resolution, so no additional dependencies that require special treatment are added. Thanks again for your input. I hope I could address some of your concerns. Best, Christos [1] https://lists.apache.org/thread/ffmjb37toj9b80dg58l4gy62hpwptdr5 [2] https://blog.gradle.org/kotlin-dsl-is-now-the-default-for-new-gradle-builds [3] https://github.com/malliaridis/solr/tree/feature/cli-module [4] https://github.com/apache/solr/tree/feature/migrate-renovate-changelog-script [5] https://kotlinlang.org/docs/custom-script-deps-tutorial.html [6] https://github.com/apache/solr/pull/3810 [7] https://github.com/apache/solr/pull/4127 [8] https://github.com/apache/solr/pull/4075 [9] https://github.com/apache/solr/blob/main/gradle/lucene-dev/lucene-dev-repo-composite.gradle [10] https://github.com/apache/solr/blob/01fc236c70732319f0d688e0231f76c64744adf6/build.gradle#L115 On Sat, Feb 14, 2026 at 8:23 PM Gus Heck <[email protected]> wrote: > *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) >
